Description

Finding
Both the Feast SDK and the feast-operator default to no_auth:

SDK default (sdk/python/feast/permissions/auth_model.py):

class AuthConfig(FeastConfigBaseModel):
    type: Literal["oidc", "kubernetes", "no_auth"] = "no_auth"
Operator default (infra/feast-operator/internal/controller/services/repo_config.go:544-546):



var defaultAuthzConfig = AuthzConfig{
    Type: NoAuthAuthType,
}
When no_auth is active, no security manager is installed. assert_permissions() returns the resource unchanged ("NoAuthConfig: allow all resources"). All feature-server, registry-server, and offline-server endpoints become unauthenticated and unauthorized. A FeatureStore CR created without .spec.authz deploys network-reachable servers with no authentication.

Repository: red-hat-data-services/feast
ASVS: V1.2.3, V13.1.4
K8s Top 10: K09 (misconfigured cluster components)
CWE: CWE-306 (Missing Authentication for Critical Function)
Severity: High

Why This Is Different From DSP
DSP (data-science-pipelines) also defaults to no in-app auth (MULTIUSER=false), but its threat model is fundamentally different:

DSP deploys one server per namespace (single-tenant) — the namespace is the security boundary

DSP uses oauth-proxy sidecar on the external Route for authentication

Feast deploys shared multi-tenant instances that serve multiple namespaces/tenants from a single FeatureStore CR

Feast does NOT deploy oauth-proxy sidecars — confirmed by reviewing the operator code. All auth is application-level via Feast's built-in modules

Feast services are ClusterIP — reachable from any pod in the cluster without NetworkPolicy restrictions

This means there is no compensating control when no_auth is the default. The Feast services are exposed to the cluster network without any authentication layer.

Impact
This is the enabler that makes other findings unauthenticated:

F-01 (RHOAIENG-68290): dill deserialization RCE becomes unauthenticated — any pod in the cluster can store a malicious UDF and achieve code execution on the feature-server

F-03 (RHOAIENG-68308): materialize DoS becomes unauthenticated — any pod can trigger full re-materialization of all tenants' features

Cross-tenant data access: any pod can read/write experiments, features, and artifacts belonging to any tenant on the shared instance

Remediation
Change the operator default from NoAuthAuthType to KubernetesAuthType so that FeatureStore CRs created without .spec.authz deploy with Kubernetes RBAC auth enabled

In the SDK, change the default to fail-closed (raise on no_auth unless FEAST_INSECURE_NO_AUTH=1 is explicitly set)

Add a validating webhook or CEL rule that warns or rejects FeatureStore CRs with no_auth in production profiles