ntkathole · Apr 7, 2026 · Mar 10, 2026 · Mar 10, 2026 · Mar 10, 2026 · Mar 10, 2026
diff --git a/.secrets.baseline b/.secrets.baseline
@@ -40,52 +40,87 @@ auth:
 With OIDC authorization, the Feast client proxies retrieve the JWT token from an OIDC server (or [Identity Provider](https://openid.net/developers/how-connect-works/))
 and append it in every request to a Feast server, using an [Authorization Bearer Token](https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#bearer).
 
-The server, in turn, uses the same OIDC server to validate the token and extract the user roles from the token itself.
+The server, in turn, uses the same OIDC server to validate the token and extract user details — including username, roles, and groups — from the token itself.
 
 Some assumptions are made in the OIDC server configuration:
 * The OIDC token refers to a client with roles matching the RBAC roles of the configured `Permission`s (*)
-* The roles are exposed in the access token that is passed to the server
+* The roles are exposed in the access token under `resource_access.<client_id>.roles`
 * The JWT token is expected to have a verified signature and not be expired. The Feast OIDC token parser logic validates for `verify_signature` and `verify_exp` so make sure that the given OIDC provider is configured to meet these requirements.
-* The preferred_username should be part of the JWT token claim.
-
+* The `preferred_username` should be part of the JWT token claim.
+* For `GroupBasedPolicy` support, the `groups` claim should be present in the access token (requires a "Group Membership" protocol mapper in Keycloak).
 
 (*) Please note that **the role match is case-sensitive**, e.g. the name of the role in the OIDC server and in the `Permission` configuration
 must be exactly the same.
 
-For example, the access token for a client `app` of a user with `reader` role should have the following `resource_access` section:
+For example, the access token for a client `app` of a user with `reader` role and membership in the `data-team` group should have the following claims:
 ```json
 {
+  "preferred_username": "alice",
   "resource_access": {
     "app": {
       "roles": [
         "reader"
       ]
     }
-  }
+  },
+  "groups": [
+    "data-team"
+  ]
 }
 ```
 
-An example of feast OIDC authorization configuration on the server side is the following: 
+#### Server-Side Configuration
+
+The server requires `auth_discovery_url` and `client_id` to validate incoming JWT tokens via JWKS:
 ```yaml
 project: my-project
 auth:
   type: oidc
-  client_id: _CLIENT_ID__
+  client_id: _CLIENT_ID_
   auth_discovery_url: _OIDC_SERVER_URL_/realms/master/.well-known/openid-configuration
 ...
 ```
 
-In case of client configuration, the following settings username, password and client_secret must be added to specify the current user:
+When the OIDC provider uses a self-signed or untrusted TLS certificate (e.g. internal Keycloak on OpenShift), set `verify_ssl` to `false` to disable certificate verification:
+```yaml
+auth:
+  type: oidc
+  client_id: _CLIENT_ID_
+  auth_discovery_url: https://keycloak.internal/realms/master/.well-known/openid-configuration
+  verify_ssl: false
+```
+
+{% hint style="warning" %}
+Setting `verify_ssl: false` disables TLS certificate verification for all OIDC provider communication (discovery, JWKS, token endpoint). Only use this in development or internal environments where you accept the security risk.
+{% endhint %}
+
+#### Client-Side Configuration
+
+The client supports multiple token source modes. The SDK resolves tokens in the following priority order:
+
+1. **Intra-communication token** — internal server-to-server calls (via `INTRA_COMMUNICATION_BASE64` env var)
+2. **`token`** — a static JWT string provided directly in the configuration
+3. **`token_env_var`** — the name of an environment variable containing the JWT
+4. **`client_secret`** — fetches a token from the OIDC provider using client credentials or ROPC flow (requires `auth_discovery_url` and `client_id`)
+5. **`FEAST_OIDC_TOKEN`** — default fallback environment variable
+6. **Kubernetes service account token** — read from `/var/run/secrets/kubernetes.io/serviceaccount/token` when running inside a pod
+
+**Token passthrough** (for use with external token providers like [kube-authkit](https://github.com/opendatahub-io/kube-authkit)):
+```yaml
+project: my-project
+auth:
+  type: oidc
+  token_env_var: FEAST_OIDC_TOKEN
+```
+
+Or with a bare `type: oidc` (no other fields) — the SDK falls back to the `FEAST_OIDC_TOKEN` environment variable or a mounted Kubernetes service account token:
 ```yaml
+project: my-project
 auth:
   type: oidc
-  ...
-  username: _USERNAME_
-  password: _PASSWORD_
-  client_secret: _CLIENT_SECRET__
 ```
 
-Below is an example of feast full OIDC client auth configuration:
+**Client credentials / ROPC flow** (existing behavior, unchanged):
 ```yaml
 project: my-project
 auth:
@@ -97,6 +132,12 @@ auth:
   auth_discovery_url: http://localhost:8080/realms/master/.well-known/openid-configuration
 ```
 
+When using client credentials or ROPC flows, the `verify_ssl` setting also applies to the discovery and token endpoint requests.
+
+#### Multi-Token Support (OIDC + Kubernetes Service Account)
+
+When the Feast server is configured with OIDC auth and deployed on Kubernetes, the `OidcTokenParser` can handle both Keycloak JWT tokens and Kubernetes service account tokens. Incoming tokens that contain a `kubernetes.io` claim are validated via the Kubernetes Token Access Review API and the namespace is extracted from the authenticated identity — no RBAC queries are performed, so the server service account only needs `tokenreviews/create` permission. All other tokens follow the standard OIDC/Keycloak JWKS validation path. This enables `NamespaceBasedPolicy` enforcement for service account tokens while using `GroupBasedPolicy` and `RoleBasedPolicy` for OIDC user tokens.
+
 ### Kubernetes RBAC Authorization
 With Kubernetes RBAC Authorization, the client uses the service account token as the authorizarion bearer token, and the
 server fetches the associated roles from the Kubernetes RBAC resources. Feast supports advanced authorization by extracting user groups and namespaces from Kubernetes tokens, enabling fine-grained access control beyond simple role matching. This is achieved by leveraging Kubernetes Token Access Review, which allows Feast to determine the groups and namespaces associated with a user or service account.

@@ -713,7 +713,34 @@ type KubernetesAuthz struct {
 // OidcAuthz defines the authorization settings for deployments using an Open ID Connect identity provider.
 // https://auth0.com/docs/authenticate/protocols/openid-connect-protocol
 type OidcAuthz struct {
-	SecretRef corev1.LocalObjectReference `json:"secretRef"`
+	// OIDC issuer URL. The operator appends /.well-known/openid-configuration to derive the discovery endpoint.
+	// +optional
+	// +kubebuilder:validation:Pattern=`^https://\S+$`
+	IssuerUrl string `json:"issuerUrl,omitempty"`
+	// Secret with OIDC properties (auth_discovery_url, client_id, client_secret). issuerUrl takes precedence.
+	// +optional
+	SecretRef *corev1.LocalObjectReference `json:"secretRef,omitempty"`
+	// Key in the Secret containing all OIDC properties as a YAML value. If unset, each key is a property.
+	// +optional
+	SecretKeyName string `json:"secretKeyName,omitempty"`
+	// Env var name for client pods to read an OIDC token from. Sets token_env_var in client config.
+	// +optional
+	TokenEnvVar *string `json:"tokenEnvVar,omitempty"`
+	// Verify SSL certificates for the OIDC provider. Defaults to true.
+	// +optional
+	VerifySSL *bool `json:"verifySSL,omitempty"`
+	// ConfigMap with the CA certificate for self-signed OIDC providers. Auto-detected on RHOAI/ODH.
+	// +optional
+	CACertConfigMap *OidcCACertConfigMap `json:"caCertConfigMap,omitempty"`
+}
+
+// OidcCACertConfigMap references a ConfigMap containing a CA certificate for OIDC provider TLS.
+type OidcCACertConfigMap struct {
+	// ConfigMap name.
+	Name string `json:"name"`
+	// Key in the ConfigMap holding the PEM certificate. Defaults to "ca-bundle.crt".
+	// +optional
+	Key string `json:"key,omitempty"`
 }
 
 // TlsConfigs configures server TLS for a feast service. in an openshift cluster, this is configured by default using service serving certificates.

@@ -50,7 +50,7 @@ metadata:
         }
       ]
     capabilities: Basic Install
-    createdAt: "2026-03-10T20:00:10Z"
+    createdAt: "2026-04-07T13:49:25Z"
     operators.operatorframework.io/builder: operator-sdk-v1.38.0
     operators.operatorframework.io/project_layout: go.kubebuilder.io/v4
   name: feast-operator.v0.61.0
@@ -175,6 +175,17 @@ spec:
           - get
           - patch
           - update
+        - apiGroups:
+          - monitoring.coreos.com
+          resources:
+          - servicemonitors
+          verbs:
+          - create
+          - delete
+          - get
+          - list
+          - patch
+          - watch
         - apiGroups:
           - policy
           resources:
@@ -259,6 +270,7 @@ spec:
                   value: quay.io/feastdev/feature-server:0.61.0
                 - name: RELATED_IMAGE_CRON_JOB
                   value: quay.io/openshift/origin-cli:4.17
+                - name: OIDC_ISSUER_URL
                 image: quay.io/feastdev/feast-operator:0.61.0
                 livenessProbe:
                   httpGet: