Follow-up to #6669. PR #6670 added optional audience and issuer fields to OidcAuthConfig for opt-in token claim verification, and review there asked for operator support as well.
The operator copies a whitelist of OIDC Secret keys (OidcOptionalSecretProperties) into the generated feature_store.yaml, so the two new fields need to be added there before operator deployments can use them. The plan is to extend that whitelist so audience and issuer set in the referenced OIDC Secret flow into the auth section the same way client_id and client_secret already do, plus a docs update in the operator security guide. When the keys are absent nothing changes.
An alternative would be first-class CRD fields, but the existing issuerUrl field on OidcAuthz already means the IdP base URL for discovery rather than the token iss claim, so Secret keys avoid a confusing name collision. Happy to go the CRD route instead if that's preferred.
PR to follow.
Follow-up to #6669. PR #6670 added optional
audienceandissuerfields toOidcAuthConfigfor opt-in token claim verification, and review there asked for operator support as well.The operator copies a whitelist of OIDC Secret keys (
OidcOptionalSecretProperties) into the generatedfeature_store.yaml, so the two new fields need to be added there before operator deployments can use them. The plan is to extend that whitelist soaudienceandissuerset in the referenced OIDC Secret flow into the auth section the same wayclient_idandclient_secretalready do, plus a docs update in the operator security guide. When the keys are absent nothing changes.An alternative would be first-class CRD fields, but the existing
issuerUrlfield onOidcAuthzalready means the IdP base URL for discovery rather than the tokenissclaim, so Secret keys avoid a confusing name collision. Happy to go the CRD route instead if that's preferred.PR to follow.