Questo contenuto non è disponibile nella lingua selezionata.
Chapter 10. Authentication and authorization for hosted control planes
The OpenShift Container Platform control plane includes a built-in OAuth server. You can obtain OAuth access tokens to authenticate to the OpenShift Container Platform API. After you create your hosted cluster, you can configure OAuth by specifying an identity provider.
10.1. Configuring the OAuth server for a hosted cluster by using the CLI Copia collegamentoCollegamento copiato negli appunti!
You can configure the internal OAuth server for your hosted cluster by using the CLI.
You can configure OAuth for the following supported identity providers:
-
oidc
-
htpasswd
-
keystone
-
ldap
-
basic-authentication
-
request-header
-
github
-
gitlab
-
google
Adding any identity provider in the OAuth configuration removes the default kubeadmin
user provider.
When you configure identity providers, you must configure at least one NodePool
replica in your hosted cluster in advance. Traffic for DNS resolution is sent through the worker nodes. You do not need to configure the NodePool
replicas in advance for the htpasswd
and request-header
identity providers.
Prerequisites
- You created your hosted cluster.
Procedure
Edit the
HostedCluster
custom resource (CR) on the hosting cluster by running the following command:oc edit <hosted_cluster_name> -n <hosted_cluster_namespace>
$ oc edit <hosted_cluster_name> -n <hosted_cluster_namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add the OAuth configuration in the
HostedCluster
CR by using the following example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Specifies your hosted cluster name.
- 2
- Specifies your hosted cluster namespace.
- 3
- This provider name is prefixed to the value of the identity claim to form an identity name. The provider name is also used to build the redirect URL.
- 4
- Defines a list of attributes to use as the email address.
- 5
- Defines a list of attributes to use as a display name.
- 6
- Defines a list of attributes to use as a preferred user name.
- 7
- Defines the ID of a client registered with the OpenID provider. You must allow the client to redirect to the
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
URL. - 8
- Defines a secret of a client registered with the OpenID provider.
- 9
- The Issuer Identifier described in the OpenID spec. You must use
https
without query or fragment component. - 10
- Defines a mapping method that controls how mappings are established between identities of this provider and
User
objects.
- Save the file to apply the changes.
10.2. Configuring the OAuth server for a hosted cluster by using the web console Copia collegamentoCollegamento copiato negli appunti!
You can configure the internal OAuth server for your hosted cluster by using the OpenShift Container Platform web console.
You can configure OAuth for the following supported identity providers:
-
oidc
-
htpasswd
-
keystone
-
ldap
-
basic-authentication
-
request-header
-
github
-
gitlab
-
google
Adding any identity provider in the OAuth configuration removes the default kubeadmin
user provider.
When you configure identity providers, you must configure at least one NodePool
replica in your hosted cluster in advance. Traffic for DNS resolution is sent through the worker nodes. You do not need to configure the NodePool
replicas in advance for the htpasswd
and request-header
identity providers.
Prerequisites
-
You logged in as a user with
cluster-admin
privileges. - You created your hosted cluster.
Procedure
-
Navigate to Home
API Explorer. -
Use the Filter by kind box to search for your
HostedCluster
resource. -
Click the
HostedCluster
resource that you want to edit. - Click the Instances tab.
-
Click the Options menu
next to your hosted cluster name entry and click Edit HostedCluster.
Add the OAuth configuration in the YAML file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- This provider name is prefixed to the value of the identity claim to form an identity name. The provider name is also used to build the redirect URL.
- 2
- Defines a list of attributes to use as the email address.
- 3
- Defines a list of attributes to use as a display name.
- 4
- Defines a list of attributes to use as a preferred user name.
- 5
- Defines the ID of a client registered with the OpenID provider. You must allow the client to redirect to the
https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
URL. - 6
- Defines a secret of a client registered with the OpenID provider.
- 7
- The Issuer Identifier described in the OpenID spec. You must use
https
without query or fragment component. - 8
- Defines a mapping method that controls how mappings are established between identities of this provider and
User
objects.
- Click Save.
10.3. Assigning components IAM roles by using the CCO in a hosted cluster on AWS Copia collegamentoCollegamento copiato negli appunti!
You can assign components IAM roles that provide short-term, limited-privilege security credentials by using the Cloud Credential Operator (CCO) in hosted clusters on Amazon Web Services (AWS). By default, the CCO runs in a hosted control plane.
The CCO supports a manual mode only for hosted clusters on AWS. By default, hosted clusters are configured in a manual mode. The management cluster might use modes other than manual.
10.4. Verifying the CCO installation in a hosted cluster on AWS Copia collegamentoCollegamento copiato negli appunti!
You can verify that the Cloud Credential Operator (CCO) is running correctly in your hosted control plane.
Prerequisites
- You configured the hosted cluster on Amazon Web Services (AWS).
Procedure
Verify that the CCO is configured in a manual mode in your hosted cluster by running the following command:
oc get cloudcredentials <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -o=jsonpath={.spec.credentialsMode}
$ oc get cloudcredentials <hosted_cluster_name> \ -n <hosted_cluster_namespace> \ -o=jsonpath={.spec.credentialsMode}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expected output
Manual
Manual
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Verify that the value for the
serviceAccountIssuer
resource is not empty by running the following command:oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \ -o jsonpath --template '{.spec.serviceAccountIssuer }'
$ oc get authentication cluster --kubeconfig <hosted_cluster_name>.kubeconfig \ -o jsonpath --template '{.spec.serviceAccountIssuer }'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example output
https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999
https://aos-hypershift-ci-oidc-29999.s3.us-east-2.amazonaws.com/hypershift-ci-29999
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.5. Enabling Operators to support CCO-based workflows with AWS STS Copia collegamentoCollegamento copiato negli appunti!
As an Operator author designing your project to run on Operator Lifecycle Manager (OLM), you can enable your Operator to authenticate against AWS on STS-enabled OpenShift Container Platform clusters by customizing your project to support the Cloud Credential Operator (CCO).
With this method, the Operator is responsible for and requires RBAC permissions for creating the CredentialsRequest
object and reading the resulting Secret
object.
By default, pods related to the Operator deployment mount a serviceAccountToken
volume so that the service account token can be referenced in the resulting Secret
object.
Prerequisities
- OpenShift Container Platform 4.14 or later
- Cluster in STS mode
- OLM-based Operator project
Procedure
Update your Operator project’s
ClusterServiceVersion
(CSV) object:Ensure your Operator has RBAC permission to create
CredentialsRequests
objects:Example 10.1. Example
clusterPermissions
listCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the following annotation to claim support for this method of CCO-based workflow with AWS STS:
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
# ... metadata: annotations: features.operators.openshift.io/token-auth-aws: "true"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Update your Operator project code:
Get the role ARN from the environment variable set on the pod by the
Subscription
object. For example:// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
// Get ENV var roleARN := os.Getenv("ROLEARN") setupLog.Info("getting role ARN", "role ARN = ", roleARN) webIdentityTokenPath := "/var/run/secrets/openshift/serviceaccount/token"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure you have a
CredentialsRequest
object ready to be patched and applied. For example:Example 10.2. Example
CredentialsRequest
object creationCopy to Clipboard Copied! Toggle word wrap Toggle overflow Alternatively, if you are starting from a
CredentialsRequest
object in YAML form (for example, as part of your Operator project code), you can handle it differently:Example 10.3. Example
CredentialsRequest
object creation in YAML formCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteAdding a
CredentialsRequest
object to the Operator bundle is not currently supported.Add the role ARN and web identity token path to the credentials request and apply it during Operator initialization:
Example 10.4. Example applying
CredentialsRequest
object during Operator initializationCopy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure your Operator can wait for a
Secret
object to show up from the CCO, as shown in the following example, which is called along with the other items you are reconciling in your Operator:Example 10.5. Example wait for
Secret
objectCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The
timeout
value is based on an estimate of how fast the CCO might detect an addedCredentialsRequest
object and generate aSecret
object. You might consider lowering the time or creating custom feedback for cluster administrators that could be wondering why the Operator is not yet accessing the cloud resources.
Set up the AWS configuration by reading the secret created by the CCO from the credentials request and creating the AWS config file containing the data from that secret:
Example 10.6. Example AWS configuration creation
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantThe secret is assumed to exist, but your Operator code should wait and retry when using this secret to give time to the CCO to create the secret.
Additionally, the wait period should eventually time out and warn users that the OpenShift Container Platform cluster version, and therefore the CCO, might be an earlier version that does not support the
CredentialsRequest
object workflow with STS detection. In such cases, instruct users that they must add a secret by using another method.Configure the AWS SDK session, for example:
Example 10.7. Example AWS SDK session configuration
Copy to Clipboard Copied! Toggle word wrap Toggle overflow