Troubleshoot OIDC in GKE on Bare Metal

This page shows you how to identify and resolve OpenID Connect (OIDC) issues with GKE on Bare Metal.

Identifying OIDC issues

When OIDC is not working for GKE on Bare Metal, 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 GKE on Bare Metal.

  1. Use kubectl logs to print the GKE Identity Service logs:

    kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

  2. 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 as htps://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.

  3. If you have identified a configuration issue in the logs, proceed to Reconfiguring OIDC.

  4. 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.

  1. 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

  2. Review the field values to confirm the specification is configured correctly for your OIDC provider.

  3. If you have identified a configuration issue in the specification, proceed to Reconfiguring OIDC.

  4. 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 base64-encoded PEM-encoded certificate for the OIDC provider. To create the string, encode the certificate, including headers, into base64. Include the resulting string in certificateAuthorityData as a single line.

Example:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

 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 resource=token-groups-claim.

If your authorization server prompts for consent for authentication with Microsoft Azure and Okta, set extraParams to prompt=consent. For Cloud Identity, set extraParams to prompt=consent,access_type=offline.

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