Configuring identity and security

This page is for platform administrators.

This page describes how to enable OpenID Connect (OIDC) authentication on user clusters, how to set up role-based access control (RBAC), and how to use Google single sign-on (SSO) for authentication. To learn more about authentication with OIDC, see Identity management with OIDC in Anthos clusters on bare metal.

Enable OIDC authentication on user clusters

OIDC authentication can be enabled during user cluster creation or on an existing user cluster. The precondition to setting up OIDC authentication is that the identity profiles to apply to the cluster already exist. See Creating Identity Profiles.

Set identity profile(s) during cluster creation

Apply identity profile during cluster creation

See Create User Clusters Through the Management Center UI for instructions on how to create user clusters. On the Cluster configuration page to create a user cluster, select the identity profiles from the AIS configurations drop-down list. These identity profiles will be applied to the user cluster.

Set identity profiles on an existing user cluster

  1. Go to the Identity and Access page.

    Identity profiles page

  2. Click Apply profiles to clusters.

    Apply profiles to existing user cluster

  3. Select the identity profiles to apply from the Profiles drop-down list.

  4. Select the clusters to apply the identity profiles to from the Clusters drop-down list.

View identity profiles applied to the user cluster

The identity profiles applied to the user cluster can be viewed from from the Identity and Access page.

Select the Cluster tab, find the user cluster to view, and then click View Configuration Details for that user cluster.

View user cluster identity configuration

Download the user cluster login configuration file

Download user cluster login configuration

On the View Configuration Details slide-out page, click Download login config.

Specify OIDC configuration from file

Create a file containing the following contents. Save this file as user-cluster-oidc-config.yaml:

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos private mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

Replace the following:

  • CONFIGURATION_NAME: The name of the OIDC configuration to create.
  • CLIENT_ID: ID for the client application that makes authentication requests to the OpenID provider.
  • CLIENT_SECRET: Secret for the client application.
  • EXTRA_PARAMS: Additional key-value parameters (comma-separated) to send to the OpenID provider.
  • ISSUER_URI: URL where authorization requests are sent to your OpenID.
  • SCOPES: Additional scopes (comma-separated) to send to the OpenID provider.
  • USER_CLAIM: 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.
  • GROUPS_CLAIM: Name of the claim in the OIDC ID Token that holds the user's group information.
  • CERT_AUTHORITY_DATA: An optional base64-encoded PEM-encoded certificate for the OIDC provider. Remove if not needed. To create the string, encode the certificate, including headers, into base64. Include the resulting string in certificateAuthorityData as a single line.

After editing the file with the desired configuration, run the following command:

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

Replace the following:

  • USER_CLUSTER_KUBECONFIG: Path to the user cluster Kubeconfig file.
  • OIDC_CONFIG: Path to the configuration file you created.

Setting up RBAC on the user cluster

This section gives an example of how to set up RBAC to grant access to individual namespaces. For more in-depth information, refer to the Kubernetes RBAC documentation.

Assume that there are two namespaces, workload-a and workload-b. The objective is to make the resources in namespace workload-a readable and writable by the user alice@example.com and workload-b readable by the user bob@example.com. alice@example.com cannot access workload-b and bob@example.com cannot access workload-a.

Create the namespaces in the user cluster:

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

In order to limit access to each namespace, the permission to each namespace must be defined. In Kubernetes, this can be performed by creating a Role.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

The verbs defined for foo-full-access define all the actions this role is allowed to perform in the namespace.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

For b-read-access the verbs defined only allow the role to query for resources.

In order for users to be granted permissions, RoleBindings have to be created. RoleBindings can include individual users as well as groups. This example shows individual users.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

The above RoleBinding (a-full-access-users) grants the user alice@example.com the permissions defined in the a-full-access Role. This means that the user alice@example.com is able to read and write to resources in the workload-a namespace.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

This RoleBinding (b-read-access-users) grants the user bob@example.com the permissions defined in the b-read-access Role. As a result, user bob@example.com, can only read resources from the workload-b namespace.

Sign in with the OIDC provider

As the admin of the user cluster, get the login configuration file to be used by all users of the user cluster to login. Refer to Download the user cluster login configuration file to get the login configuration from the Anthos private mode Management Center UI. Alternatively, you can create the login configuration file by executing:

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=USER_CLUSTER_NAME-actl-auth-login-config.yaml

Distribute USER_CLUSTER_NAME-actl-auth-login-config.yaml to users of the user cluster.

Authenticate with the OIDC provider and follow the instructions in the command line:

actl auth login --login-config=USER_CLUSTER_NAME-actl-auth-login-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig \
  --preferred-auth="CONFIGURATION_NAME"

Replace USER_CLUSTER_NAME with the name of the user cluster as shown in the Admin Console. --kubeconfig=USER_CLUSTER_NAME-cluster-oidc-kubeconfig is the output Kubeconfig file name. Replace CONFIGURATION_NAME with the identity profile name to authenticate with. Open USER_CLUSTER_NAME-actl-auth-login-config.yaml to see the profile names.

Use the new Kubeconfig with kubectl as follows:

kubectl --kubeconfig=./USER_CLUSTER_NAME-cluster-oidc-kubeconfig get pods -A

Authenticating with Google SSO

Note that Google SSO is not available in Anthos private mode, and this section is for demo and test purposes only. If you want to use Google SSO, both the cluster and the browsers must be able to contact Google's SSO servers. Google's SSO servers do not need to be able to contact the user clusters.

  1. Log in to the Google Cloud Console and select a valid Project.
  2. Access the "API & Services > OAuth Consent Screen" Section.
  3. Create a new OAuth Consent Screen. This information is generally shown to users.
    1. Set the Application Home Page to the Admin URL.
  4. In the API & Services > Credentials section:
    1. Click Create Credentials.
    2. Create a new OAuth Client ID.
    3. Set the Application Type to be Web Application.
    4. Choose a relevant name.
    5. For the JavaScript origins, set https://anthos.example.com (supposing that https://anthos.example.com is your domain name for the Management Center).
    6. For the Authorized redirect URIs, set:
      • https://anthos.example.com/_gcp_anthos_oidc_callback
      • http://localhost:9879/callback
  5. Copy the ClientID and Client Secret to the AdminUI configuration.
  6. Set the OIDC Provider URL to https://accounts.google.com.
  7. Set Username Claim to email and Scopes to openid email.
  8. Set Extra Parameters to prompt=consent,access_type=offline. Otherwise, you can't log in with the Kubernetes API server.
  9. Add initial list of user emails (separated by commas) to be granted Platform Admin permissions.
  10. Click Save.

Google SSO

Audit logging

Kubernetes auditing is enabled for Anthos private mode, providing the approach to check administrative access and actions on the platform.

Currently audit logging cannot be customized for parameters such as retention time, refresh rate, or chunk size. The audit level is Metadata, which logs request metadata (requesting user, timestamp, resource, verb) but not request or response body.

Audit logging is enabled in Anthos private mode by default. See Logging and monitoring for detailed steps on accessing audit logs.