This page shows you how to identify and resolve OpenID Connect (OIDC) issues with Google Distributed Cloud.
Identifying OIDC issues
When OIDC is not working for Google Distributed Cloud, typically the OIDC specification within the cluster config file has been improperly configured. This section provides instructions for reviewing logs and the OIDC specification to help identify the cause of an OIDC problem.
Reviewing the GKE Identity Service logs
GKE Identity Service supports OIDC in Google Distributed Cloud.
Use
kubectl logs
to print the GKE Identity Service logs:kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \ deployment/ais --all-containers=true
Review the logs for errors that can help you diagnose OIDC problems.
If you are unable to authenticate with OIDC, GKE Identity Service logs provide the most relevant and useful information for debugging the problem.
For example, if the OIDC specification (in the cluster config file) has a typo in the
issuerURL
field, such ashtps://accounts.google.com
(missing a "t" in https), the GKE Identity Service logs will contain an entry like this:OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
If you have identified a configuration issue in the logs, proceed to Reconfiguring OIDC.
If you are unable to diagnose and resolve the problem yourself, engage with Cloud Customer Care.
Cloud Customer Care will need the GKE Identity Service logs and the OIDC specification to diagnose and resolve OIDC problems.
Checking the OIDC specification in your cluster
The OIDC information for your cluster is specified in the clientconfig
object
in the kube-public
namespace.
Use
kubectl get
to print the OIDC resource for your cluster:kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \ clientconfig.authentication.gke.io default -o yaml
Review the field values to confirm the specification is configured correctly for your OIDC provider.
If you have identified a configuration issue in the specification, proceed to Reconfiguring OIDC.
If you are unable to diagnose and resolve the problem yourself, engage with Cloud Customer Care.
Cloud Customer Care will need the GKE Identity Service logs and the OIDC specification to diagnose and resolve OIDC problems.
Reconfiguring OIDC
If you identified problems in either the GKE Identity Service logs or the
the clientconfig
object, you can reconfigure OIDC in your cluster (without
re-creating the cluster) to address them. To reconfigure OIDC, edit the KRM
default object of type clientconfig
in thekube-public
namespace:
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
Details from the ClientConfig CRD are used to configure OIDC for both the Google Cloud console and the Authentication plugin for GKE Enterprise. For details about the OIDC Information included in the ClientConfig CRD, see the following YAML and associated table of field descriptions.
authentication: - name: oidc oidc: certificateAuthorityData: CERTIFICATE_STRING clientID: CLIENT_ID clientSecret: CLIENT_SECRET cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc" deployCloudConsoleProxy: PROXY_BOOLEAN extraParams: EXTRA_PARAMS groupsClaim: GROUPS_CLAIM groupPrefix: GROUP_PREFIX issuerURI: ISSUER_URI kubectlRedirectURI: KUBECTL_REDIRECT_URI scopes: SCOPES userClaim: USER_CLAIM userPrefix: USER_PREFIX proxy: PROXY_URL
The following table describes the fields of the ClientConfig CRD oidc
object.
Field | Required | Description | Format |
---|---|---|---|
name | Yes | The name of the OIDC configuration to create. | String |
certificateAuthorityData | No | A Example: |
String |
clientID | Yes | ID for the client application that makes authentication requests to the OpenID provider. | String |
clientSecret | No | Shared secret between the OIDC client application and the OIDC provider. | String |
extraParams | No |
Additional key-value parameters to send to the OpenID provider. If you are
authorizing a group, pass in If your authorization server prompts for consent for authentication with
Microsoft Azure and Okta, set |
Comma-delimited list |
groupsClaim | No | JWT claim that the provider uses to return your security groups. | String |
groupPrefix | No | Prefix prepended to group claims to prevent clashes with existing names.
For example, if you have two groups named foobar , add a prefix
gid- . The resulting group is gid-foobar . |
String |
issuerURI | Yes | URL where authorization requests are sent to your OpenID, such as
https://example.com/adfs . The Kubernetes API server uses this URL
to discover public keys for verifying tokens. The URI must use HTTPS. |
URL String |
kubectlRedirectURI | Yes | The redirect URL that kubectl uses for authorization. |
URL String |
scopes | Yes | Additional scopes to send to the OpenID provider. Microsoft Azure and Okta
require the offline_access scope. |
Comma-delimited list |
userClaim | No | JWT claim to use as the username. You can choose other claims, such as email or name, depending on the OpenID provider. However, claims other than email are prefixed with the issuer URL to prevent naming clashes. | String |
userPrefix | No | Prefix prepended to username claims to prevent clashes with existing names. | String |
proxy | No | Proxy server to use for the auth method, if applicable.
For example: http://user:password@10.10.10.10:8888 |
String |