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
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
Go to the Identity and Access page.
Click Apply profiles to clusters.
Select the identity profiles to apply from the Profiles drop-down list.
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.
Download the user cluster login configuration file
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
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,
objective is to make the resources in namespace
workload-a readable and
writable by the user firstname.lastname@example.org and
workload-b readable by the user email@example.com.
firstname.lastname@example.org cannot access
email@example.com cannot access
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
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
b-read-access the verbs defined only allow the role to query for
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: firstname.lastname@example.org # 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
email@example.com the permissions defined in the
a-full-access Role. This means that the user firstname.lastname@example.org is able to read
and write to resources in the
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: email@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
firstname.lastname@example.org the permissions defined in the
b-read-access Role. As a result, user
email@example.com, can only read resources from the
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
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"
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.
CONFIGURATION_NAME with the identity profile
name to authenticate with. Open
USER_CLUSTER_NAME-actl-auth-login-config.yaml to see the
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.
- Log in to the Google Cloud Console and select a valid Project.
- Access the "API & Services > OAuth Consent Screen" Section.
- Create a new OAuth Consent Screen. This information is generally shown to
- Set the Application Home Page to the Admin URL.
- In the API & Services > Credentials section:
- Click Create Credentials.
- Create a new OAuth Client ID.
- Set the Application Type to be Web Application.
- Choose a relevant name.
https://anthos.example.comis your domain name for the Management Center).
- For the Authorized redirect URIs, set:
- Copy the ClientID and Client Secret to the AdminUI configuration.
- Set the OIDC Provider URL to
- Set Extra Parameters to
prompt=consent,access_type=offline. Otherwise, you can't log in with the Kubernetes API server.
- Add initial list of user emails (separated by commas) to be granted Platform Admin permissions.
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.