diff --git a/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc b/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc index e5afcb5b90d6..c3687a4870b3 100644 --- a/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc +++ b/authentication/assuming-an-aws-iam-role-for-a-service-account.adoc @@ -1,6 +1,6 @@ :_mod-docs-content-type: ASSEMBLY [id="assuming-an-aws-iam-role-for-a-service-account"] -= Assuming an AWS IAM role for a service account += Assume an AWS IAM role for a service account include::_attributes/common-attributes.adoc[] ifdef::openshift-rosa,openshift-dedicated,openshift-rosa-hcp[] @@ -34,7 +34,7 @@ include::modules/deploying-a-pod-that-includes-an-aws-sdk.adoc[leveloffset=+2] include::modules/verifying-the-assumed-iam-role-in-your-pod.adoc[leveloffset=+2] [role="_additional-resources"] -[id="additional-resources_configuring-alert-notifications"] +[id="additional-resources_{context}"] == Additional resources * link:https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html[AWS documentation on IAM roles for service accounts] diff --git a/authentication/osd-admin-roles.adoc b/authentication/osd-admin-roles.adoc index de03f05e61f3..13d643a30a4f 100644 --- a/authentication/osd-admin-roles.adoc +++ b/authentication/osd-admin-roles.adoc @@ -1,6 +1,6 @@ :_mod-docs-content-type: ASSEMBLY [id="osd-admin-roles"] -= Managing administration roles and users += Manage administration roles and users include::_attributes/attributes-openshift-dedicated.adoc[] :context: osd-admin-roles diff --git a/authentication/osd-revoking-cluster-privileges.adoc b/authentication/osd-revoking-cluster-privileges.adoc index a80c2b7f660b..b4e708a8d877 100644 --- a/authentication/osd-revoking-cluster-privileges.adoc +++ b/authentication/osd-revoking-cluster-privileges.adoc @@ -1,6 +1,6 @@ :_mod-docs-content-type: ASSEMBLY [id="osd-revoking-cluster-privileges"] -= Revoking privileges and access to an {product-title} cluster += Revoke privileges and access to an {product-title} cluster include::_attributes/attributes-openshift-dedicated.adoc[] :context: osd-revoking-cluster-privileges diff --git a/authentication/sd-configuring-identity-providers.adoc b/authentication/sd-configuring-identity-providers.adoc index 0d7d420e21ec..e3a7b8d4900a 100644 --- a/authentication/sd-configuring-identity-providers.adoc +++ b/authentication/sd-configuring-identity-providers.adoc @@ -26,7 +26,7 @@ include::modules/config-htpasswd-idp-webui.adoc[leveloffset=+2] include::modules/config-htpasswd-idp-from-file.adoc[leveloffset=+2] ifdef::openshift-rosa-hcp,openshift-rosa[] include::modules/rosa-config-htpasswd-idp-cli.adoc[leveloffset=+2] -include::modules/rosa-config-htpasswd-idp-cli-file.adoc[leveloffset=+3] +include::modules/rosa-config-htpasswd-idp-cli-file.adoc[leveloffset=+2] include::modules/config-htpasswd-idp-terraform.adoc[leveloffset=+2] endif::openshift-rosa-hcp,openshift-rosa[] ifdef::openshift-dedicated[] @@ -43,5 +43,5 @@ ifdef::openshift-rosa[] * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-understanding-the-deployment-workflow[Understanding the ROSA with STS deployment workflow] endif::openshift-rosa[] * link:https://httpd.apache.org/docs/current/misc/password_encryptions.html[Apache Password Formats] -* link:https://developers.google.com/identity/protocols/OpenIDConnect[Google's OpenID Connect integration] -* link:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow] \ No newline at end of file +* link:https://developers.google.com/identity/protocols/OpenIDConnect[Google OpenID Connect integration] +* link:https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow] \ No newline at end of file diff --git a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-idp.adoc b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-idp.adoc index 6efdffe23145..78f8c525d760 100644 --- a/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-idp.adoc +++ b/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-idp.adoc @@ -8,7 +8,7 @@ include::_attributes/attributes-openshift-dedicated.adoc[] toc::[] [role="_abstract"] -To log in to your cluster, set up an identity provider (IDP). This tutorial uses GitHub as an example IDP. See the full list of xref:../../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc#understanding-idp-supported_rosa-sts-config-identity-providers[IDPs supported by ROSA]. +To log in to your cluster, set up an identity provider (IDP). This tutorial uses GitHub as an example IDP. See the full list of xref:../../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc#understanding-idp_rosa-sts-config-identity-providers[IDPs supported by ROSA]. include::modules/cloud-experts-getting-started-idp-creating.adoc[leveloffset=+1] diff --git a/modules/assuming-an-aws-iam-role-in-your-own-pods.adoc b/modules/assuming-an-aws-iam-role-in-your-own-pods.adoc index 4db516218194..6eb4806e54d5 100644 --- a/modules/assuming-an-aws-iam-role-in-your-own-pods.adoc +++ b/modules/assuming-an-aws-iam-role-in-your-own-pods.adoc @@ -4,7 +4,7 @@ :_mod-docs-content-type: CONCEPT [id="assuming-an-aws-iam-role-in-your-own-pods_{context}"] -= Assuming an AWS IAM role in your own pods += About assuming AWS IAM roles in your own pods [role="_abstract"] You can enable a service account to assume an AWS Identity and Access Management (IAM) role in a pod deployed in a user-defined project. diff --git a/modules/authentication-overview.adoc b/modules/authentication-overview.adoc index 7486deb245ac..db6cbee04df9 100644 --- a/modules/authentication-overview.adoc +++ b/modules/authentication-overview.adoc @@ -26,7 +26,7 @@ If you do not present a valid access token or certificate, your request is unaut ==== ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -An administrator can configure authentication by configuring an identity provider. You can define any xref:../authentication/sd-configuring-identity-providers.adoc#understanding-idp-supported_sd-configuring-identity-providers[supported identity provider in {product-title}] and add it to your cluster. +An administrator can configure authentication by configuring an identity provider. You can define any xref:../authentication/sd-configuring-identity-providers.adoc#understanding-idp_sd-configuring-identity-providers[supported identity provider in {product-title}] and add it to your cluster. endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] diff --git a/modules/config-github-idp.adoc b/modules/config-github-idp.adoc index 3df32401478c..b51670fbce44 100644 --- a/modules/config-github-idp.adoc +++ b/modules/config-github-idp.adoc @@ -5,10 +5,10 @@ :_mod-docs-content-type: PROCEDURE [id="config-github-idp_{context}"] -= Configuring a GitHub identity provider += Configure a GitHub identity provider [role="_abstract"] -Configure a GitHub identity provider to validate user names and passwords against GitHub or GitHub Enterprise's OAuth authentication server and access your {product-title} cluster. OAuth facilitates a token exchange flow between {product-title} and GitHub or GitHub Enterprise. +Configure a GitHub identity provider to validate user names and passwords against the GitHub or GitHub Enterprise OAuth authentication server and access your {product-title} cluster. OAuth facilitates a token exchange flow between {product-title} and GitHub or GitHub Enterprise. [WARNING] ==== @@ -17,7 +17,7 @@ Configuring GitHub authentication allows users to log in to {product-title} with .Prerequisites -* The OAuth application must be created directly within the GitHub link:https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-organization-settings[organization settings] by the GitHub organization administrator. +* The OAuth application is created directly within the GitHub link:https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-organization-settings[organization settings] by the GitHub organization administrator. * link:https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams[GitHub organizations or teams] are set up in your GitHub account. .Procedure @@ -30,13 +30,13 @@ Configuring GitHub authentication allows users to log in to {product-title} with + [NOTE] ==== -You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers. +You can also click the *Add OAuth configuration* link in the warning message displayed after cluster creation to configure your identity providers. ==== . Select *GitHub* from the drop-down menu. . Enter a unique name for the identity provider. This name cannot be changed later. -** An *OAuth callback URL* is automatically generated in the provided field. You will use this to register the GitHub application. +** An *OAuth callback URL* is automatically generated in the provided field. Use this URL to register the GitHub application. + ---- https://oauth-openshift.apps../oauth2callback/ diff --git a/modules/config-gitlab-idp.adoc b/modules/config-gitlab-idp.adoc index ad273e1935a2..27472dfa2b00 100644 --- a/modules/config-gitlab-idp.adoc +++ b/modules/config-gitlab-idp.adoc @@ -5,14 +5,14 @@ :_mod-docs-content-type: PROCEDURE [id="config-gitlab-idp_{context}"] -= Configuring a GitLab identity provider += Configure a GitLab identity provider [role="_abstract"] -Configure a GitLab identity provider to use link:https://gitlab.com/[GitLab.com] or any other GitLab instance as an identity provider. +Configure a GitLab identity provider to use `gitlab.com` or any other GitLab instance so that users can log in to your cluster with their GitLab credentials. .Prerequisites -- If you use GitLab version 7.7.0 to 11.0, you connect using the link:http://doc.gitlab.com/ce/integration/oauth_provider.html[OAuth integration]. If you use GitLab version 11.1 or later, you can use link:https://docs.gitlab.com/ce/integration/openid_connect_provider.html[OpenID Connect] (OIDC) to connect instead of OAuth. +* If you use GitLab version 7.7.0 to 11.0, you connect using the link:https://docs.gitlab.com/ee/integration/oauth_provider.html[OAuth integration]. If you use GitLab version 11.1 or later, you can use link:https://docs.gitlab.com/ee/integration/openid_connect_provider.html[OpenID Connect] (OIDC) to connect instead of OAuth. .Procedure @@ -24,13 +24,13 @@ Configure a GitLab identity provider to use link:https://gitlab.com/[GitLab.com] + [NOTE] ==== -You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers. +You can also click the *Add OAuth configuration* link in the warning message displayed after cluster creation to configure your identity providers. ==== . Select *GitLab* from the drop-down menu. . Enter a unique name for the identity provider. This name cannot be changed later. -** An *OAuth callback URL* is automatically generated in the provided field. You will provide this URL to GitLab. +** An *OAuth callback URL* is automatically generated in the provided field. Provide this URL to GitLab. + ifndef::openshift-rosa-hcp[] ---- diff --git a/modules/config-google-idp.adoc b/modules/config-google-idp.adoc index 4829219b1f38..d728ab055194 100644 --- a/modules/config-google-idp.adoc +++ b/modules/config-google-idp.adoc @@ -5,16 +5,14 @@ :_mod-docs-content-type: PROCEDURE [id="config-google-idp_{context}"] -= Configuring a Google identity provider += Configure a Google identity provider [role="_abstract"] Configure a Google identity provider to allow users to authenticate with their Google credentials. [WARNING] ==== -Using Google as an identity provider allows any Google user to authenticate to your server. -You can limit authentication to members of a specific hosted domain with the -`hostedDomain` configuration attribute. +Using Google as an identity provider allows any Google user to authenticate to your server. You can limit authentication to members of a specific hosted domain with the `hostedDomain` configuration attribute. ==== .Procedure @@ -27,13 +25,13 @@ You can limit authentication to members of a specific hosted domain with the + [NOTE] ==== -You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers. +You can also click the *Add OAuth configuration* link in the warning message displayed after cluster creation to configure your identity providers. ==== . Select *Google* from the drop-down menu. . Enter a unique name for the identity provider. This name cannot be changed later. -** An *OAuth callback URL* is automatically generated in the provided field. You will provide this URL to Google. +** An *OAuth callback URL* is automatically generated in the provided field. Provide this URL to Google. + ifndef::openshift-rosa-hcp[] ---- @@ -52,7 +50,7 @@ For example: https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/google ---- -. Configure a Google identity provider using link:https://developers.google.com/identity/protocols/OpenIDConnect[Google's OpenID Connect integration]. +. Configure a Google identity provider using link:https://developers.google.com/identity/protocols/OpenIDConnect[Google OpenID Connect integration]. . Return to {product-title} and select a mapping method from the drop-down menu. *Claim* is recommended in most cases. diff --git a/modules/config-htpasswd-idp-terraform.adoc b/modules/config-htpasswd-idp-terraform.adoc index d0cf48f3b322..883c8dc281dd 100644 --- a/modules/config-htpasswd-idp-terraform.adoc +++ b/modules/config-htpasswd-idp-terraform.adoc @@ -9,7 +9,7 @@ ifeval::["{context}" == "rosa-hcp-creating-a-cluster-quickly-terraform"] endif::[] [id="config-htpasswd-idp-terraform_{context}"] -= Configuring an htpasswd identity provider with Terraform += Configure an htpasswd identity provider with Terraform ifdef::tf-config[] [role="_abstract"] @@ -112,7 +112,7 @@ $ cat<<-EOF>htpasswd_idp.tf EOF ---- + -You must replace the `` placeholder with the 32-digit ID for your cluster. To find that value, run `rosa list clusters | awk '{print $1}'`. You also must replace the `` placeholder with the username you want to create as well as a password for the `` placeholder. +You must replace the `` placeholder with the 32-digit ID for your cluster. To find that value, run `rosa list clusters | awk '{print $1}'`. You also must replace the `` placeholder with the username you want to create and a password for the `` placeholder. . Run the following command to configure Terraform to create your resources based on your Terraform files: + diff --git a/modules/config-ldap-idp.adoc b/modules/config-ldap-idp.adoc index acd33bd566ec..f5489a4811d1 100644 --- a/modules/config-ldap-idp.adoc +++ b/modules/config-ldap-idp.adoc @@ -5,15 +5,14 @@ :_mod-docs-content-type: PROCEDURE [id="config-ldap-idp_{context}"] -= Configuring a LDAP identity provider += Configure an LDAP identity provider [role="_abstract"] Configure the LDAP identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication. .Prerequisites -* When configuring a LDAP identity provider, you will need to enter a configured *LDAP URL*. The configured URL is an RFC 2255 URL, which specifies the LDAP host and -search parameters to use. The syntax of the URL is: +* When configuring an LDAP identity provider, you need to enter a configured *LDAP URL*. The configured URL is an RFC 2255 URL, which specifies the LDAP host and search parameters to use. The syntax of the URL is: + ---- ldap://host:port/basedn?attribute?scope?filter @@ -26,22 +25,13 @@ ldap://host:port/basedn?attribute?scope?filter (LDAPS), use `ldaps` instead. .^|`host:port` | The name and port of the LDAP server. Defaults to `localhost:389` for ldap and `localhost:636` for LDAPS. -.^|`basedn` | The DN of the branch of the directory where all searches should -start from. At the very least, this must be the top of your directory tree, but -it could also specify a subtree in the directory. -.^|`attribute` | The attribute to search for. Although RFC 2255 allows a -comma-separated list of attributes, only the first attribute will be used, no -matter how many are provided. If no attributes are provided, the default is to -use `uid`. It is recommended to choose an attribute that will be unique across -all entries in the subtree you will be using. -.^|`scope` | The scope of the search. Can be either `one` or `sub`. -If the scope is not provided, the default is to use a scope of `sub`. -.^|`filter` | A valid LDAP search filter. If not provided, defaults to -`(objectClass=*)` +.^|`basedn` | The DN of the branch of the directory where all searches should start from. At the very least, this must be the top of your directory tree, but it could also specify a subtree in the directory. +.^|`attribute` | The attribute to search for. Although RFC 2255 allows a comma-separated list of attributes, only the first attribute is used, no matter how many are provided. If no attributes are provided, the default is to use `uid`. Choose an attribute that is unique across all entries in the subtree you are using. +.^|`scope` | The scope of the search. Can be either `one` or `sub`. If the scope is not provided, the default is to use a scope of `sub`. +.^|`filter` | A valid LDAP search filter. If not provided, defaults to `(objectClass=*)` |=== + -When doing searches, the attribute, filter, and provided user name are combined -to create a search filter that looks like: +When doing searches, the attribute, filter, and provided user name are combined to create a search filter that looks like: + ---- (&()(=)) @@ -62,7 +52,7 @@ If the LDAP directory requires authentication to search, specify a `bindDN` and + [NOTE] ==== -You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers. +You can also click the *Add OAuth configuration* link in the warning message displayed after cluster creation to configure your identity providers. ==== . Select *LDAP* from the drop-down menu. @@ -80,7 +70,7 @@ You can also click the *Add Oauth configuration* link in the warning message dis ** Optional: Enter a *Preferred username* attribute whose value should be used as the display name. Click *Add more* to add multiple preferred username attributes. ** Optional: Enter an *Email* attribute whose value should be used as the email address. Click *Add more* to add multiple email attributes. -. Optional: Click *Show advanced Options* to add a certificate authority (CA) file to your LDAP identity provider to validate server certificates for the configured URL. Click *Browse* to locate and attach a *CA file* to the identity provider. +. Optional: Click *Show advanced options* to add a certificate authority (CA) file to your LDAP identity provider to validate server certificates for the configured URL. Click *Browse* to locate and attach a *CA file* to the identity provider. . Optional: Under the advanced options, you can choose to make the LDAP provider *Insecure*. If you select this option, a CA file cannot be used. + diff --git a/modules/config-openid-idp.adoc b/modules/config-openid-idp.adoc index 4bd0c59be683..0ce13b4eb74e 100644 --- a/modules/config-openid-idp.adoc +++ b/modules/config-openid-idp.adoc @@ -5,27 +5,21 @@ :_mod-docs-content-type: PROCEDURE [id="config-openid-idp_{context}"] -= Configuring an OpenID identity provider += Configure an OpenID identity provider [role="_abstract"] -Configure an OpenID identity provider to integrate with an OpenID Connect identity provider using an link:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow]. +Configure an OpenID identity provider to integrate with an OpenID Connect identity provider by using an Authorization Code Flow so that users can authenticate by using their existing OpenID Connect credentials. [IMPORTANT] ==== -The Authentication Operator in {product-title} requires that the configured -OpenID Connect identity provider implements the -link:https://openid.net/specs/openid-connect-discovery-1_0.html[OpenID Connect Discovery] -specification. +The Authentication Operator in {product-title} requires that the configured OpenID Connect identity provider implements the link:https://openid.net/specs/openid-connect-discovery-1_0.html[OpenID Connect Discovery] specification. ==== -Claims are read from the JWT `id_token` returned from the OpenID identity -provider and, if specified, from the JSON returned by the Issuer URL. +Claims are read from the JWT `id_token` returned from the OpenID identity provider and, if specified, from the JSON returned by the Issuer URL. At least one claim must be configured to use as the user's identity. -You can also indicate which claims to use as the user's preferred user name, -display name, and email address. If multiple claims are specified, the first one -with a non-empty value is used. The standard claims are: +You can also indicate which claims to use as the user's preferred user name, display name, and email address. If multiple claims are specified, the first one with a non-empty value is used. The standard claims are: [cols="1,2",options="header"] |=== @@ -34,10 +28,7 @@ with a non-empty value is used. The standard claims are: |Description |`preferred_username` -|The preferred user name when provisioning a user. A -shorthand name that the user wants to be referred to as, such as `janedoe`. Typically -a value that corresponding to the user's login or username in the authentication -system, such as username or email. +|The preferred user name when provisioning a user. A shorthand name that the user wants to be referred to as, such as `janedoe`. Typically a value that corresponds to the user's login or username in the authentication system, such as username or email. |`email` |Email address. @@ -64,7 +55,7 @@ for more information. + [NOTE] ==== -You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers. +You can also click the *Add OAuth configuration* link in the warning message displayed after cluster creation to configure your identity providers. ==== . Select *OpenID* from the drop-down menu. @@ -99,11 +90,11 @@ https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/openid . Enter an *Email* attribute whose value should be used as the email address. Click *Add more* to add multiple email attributes. -. Enter a *Name* attribute whose value should be used as the preferred username. Click *Add more* to add multiple preferred usernames. +. Enter a *Name* attribute whose value should be used as the display name. Click *Add more* to add multiple display names. -. Enter a *Preferred username* attribute whose value should be used as the display name. Click *Add more* to add multiple display names. +. Enter a *Preferred username* attribute whose value should be used as the preferred username. Click *Add more* to add multiple preferred usernames. -. Optional: Click *Show advanced Options* to add a certificate authority (CA) file to your OpenID identity provider. +. Optional: Click *Show advanced options* to add a certificate authority (CA) file to your OpenID identity provider. . Optional: Under the advanced options, you can add *Additional scopes*. By default, the `OpenID` scope is requested. diff --git a/modules/creating-a-service-account-in-your-project.adoc b/modules/creating-a-service-account-in-your-project.adoc index 59014e50447e..854ab4e51e2d 100644 --- a/modules/creating-a-service-account-in-your-project.adoc +++ b/modules/creating-a-service-account-in-your-project.adoc @@ -4,7 +4,7 @@ :_mod-docs-content-type: PROCEDURE [id="creating-a-service-account-in-your-project_{context}"] -= Creating a service account in your project += Create a service account in your project [role="_abstract"] To allow workloads in a project to assume an AWS Identity and Access Management (IAM) role, you can create a service account configured with your IAM role in that project. By using a service account, you can enable any of the workloads in that project to use the same role by assigning a service account to that workload. @@ -13,7 +13,7 @@ To allow workloads in a project to assume an AWS Identity and Access Management * You have created an AWS IAM role for your service account. For more information, see _Setting up an AWS IAM role for a service account_. * You have access to a {product-title} with AWS Security Token Service (STS) cluster. Admin-level user privileges are not required. -* You have installed the OpenShift CLI (`oc`). +* You have installed the {oc-first}. .Procedure diff --git a/modules/creating-an-example-aws-sdk-container-image.adoc b/modules/creating-an-example-aws-sdk-container-image.adoc index 4fc77ab878b1..2132e3310b0c 100644 --- a/modules/creating-an-example-aws-sdk-container-image.adoc +++ b/modules/creating-an-example-aws-sdk-container-image.adoc @@ -4,10 +4,10 @@ :_mod-docs-content-type: PROCEDURE [id="creating-an-example-aws-sdk-container-image_{context}"] -= Creating an AWS SDK container image += Create an AWS SDK container image [role="_abstract"] -To deploy pods that can run AWS SDK operations in your cluster, your pods must contain a version of the AWS SDK. You can include an SDK in the container image for use with your pods. +To deploy pods that can run AWS software development kit (SDK) operations in your cluster, your pods must contain a version of the AWS SDK. You can include an SDK in the container image for use with your pods. These example steps use Podman to create the container image and Quay.io to host the image. For more information about Quay.io, see link:https://docs.quay.io/solution/getting-started.html[Getting Started with Quay.io]. The container image can be used to deploy pods that can run AWS SDK operations. diff --git a/modules/deploying-a-pod-that-includes-an-aws-sdk.adoc b/modules/deploying-a-pod-that-includes-an-aws-sdk.adoc index 5d8d91daaecf..12a72867e180 100644 --- a/modules/deploying-a-pod-that-includes-an-aws-sdk.adoc +++ b/modules/deploying-a-pod-that-includes-an-aws-sdk.adoc @@ -4,18 +4,18 @@ :_mod-docs-content-type: PROCEDURE [id="deploying-a-pod-that-includes-an-aws-sdk_{context}"] -= Deploying a pod that includes an AWS SDK += Deploy a pod that includes an AWS SDK [role="_abstract"] -To enable your application to automatically assume an AWS IAM role within a pod, you can assign a previously created service account to the pod so that it can automatically detect which IAM role to assume. +To enable your application to automatically assume an AWS Identity and Access Management (IAM) role within a pod, you can assign a previously created service account to the pod so that it can automatically detect which IAM role to assume. In your pod configuration, specify the service account that includes the `eks.amazonaws.com/role-arn` annotation. With the service account reference in place for your pod, the pod identity webhook injects the AWS environment variables, the volume mount, and the token volume into your pod. The pod mutation enables the service account to automatically assume the AWS IAM role in the pod. .Prerequisites -* You have created an AWS Identity and Access Management (IAM) role for your service account. For more information, see _Setting up an AWS IAM role for a service account_. +* You have created an AWS IAM role for your service account. For more information, see _Setting up an AWS IAM role for a service account_. * You have access to a {product-title} cluster that uses the AWS Security Token Service (STS). Admin-level user privileges are not required. -* You have installed the OpenShift CLI (`oc`). +* You have installed the {oc-first}. * You have created a service account in your project that includes an `eks.amazonaws.com/role-arn` annotation that references the Amazon Resource Name (ARN) for the IAM role that you want the service account to assume. * You have a container image that includes an AWS SDK and the image is available to your cluster. For detailed steps, see _Creating an example AWS SDK container image_. + diff --git a/modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc b/modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc index 2e35d7e9d928..549678a679db 100644 --- a/modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc +++ b/modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc @@ -5,7 +5,7 @@ :_mod-docs-content-type: CONCEPT [id="how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects_{context}"] -= How service accounts assume AWS IAM roles in SRE owned projects += How service accounts assume AWS IAM roles in SRE-owned projects [role="_abstract"] When you install a {product-title} @@ -15,18 +15,18 @@ endif::openshift-rosa-hcp[] ifndef::openshift-rosa-hcp[] that uses the AWS Security Token Service (STS), endif::openshift-rosa-hcp[] -cluster-specific Operator AWS Identity and Access Management (IAM) roles are created. These IAM roles permit the ROSA cluster Operators to run core OpenShift functionality. +cluster-specific Operator AWS Identity and Access Management (IAM) roles are created. These IAM roles permit the ROSA cluster Operators, managed by Red{nbsp}Hat Site Reliability Engineering (SRE), to run core OpenShift functionality. Cluster Operators use service accounts to assume IAM roles. When a service account assumes an IAM role, temporary AWS STS credentials are provided for the service account to use in the cluster Operator's pod. If the assumed role has the necessary AWS privileges, the service account can run AWS SDK operations in the pod. [id="workflow-for-assuming-aws-iam-roles-in-sre-owned-projects_{context}"] -== Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE owned projects +== Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE-owned projects -The following diagram illustrates the workflow for assuming AWS IAM roles in SRE owned projects: +The following diagram illustrates the workflow for assuming AWS IAM roles in SRE-owned projects: -.Workflow for assuming AWS IAM roles in SRE owned projects -image::workflow-assuming-aws-iam-roles-sre-owned-projects.png[Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE owned projects] +.Workflow for assuming AWS IAM roles in SRE-owned projects +image::workflow-assuming-aws-iam-roles-sre-owned-projects.png[Workflow for assuming AWS IAM roles in Red{nbsp}Hat SRE-owned projects] The workflow has the following stages: diff --git a/modules/identity-provider-parameters.adoc b/modules/identity-provider-parameters.adoc index afc69d3f91b2..250dbb4532e4 100644 --- a/modules/identity-provider-parameters.adoc +++ b/modules/identity-provider-parameters.adoc @@ -13,27 +13,14 @@ The following parameters are common to all identity providers: [cols="2a,8a",options="header"] |=== |Parameter | Description -|`name` | The provider name is prefixed to provider user names to form an -identity name. +|`name` | The provider name is prefixed to provider user names to form an identity name. -|`mappingMethod` | Defines how new identities are mapped to users when they log in. -Enter one of the following values: +|`mappingMethod` | Defines how new identities are mapped to users when they log in. Enter one of the following values: -claim:: The default value. Provisions a user with the identity's preferred -user name. Fails if a user with that user name is already mapped to another -identity. -lookup:: Looks up an existing identity, user identity mapping, and user, -but does not automatically provision users or identities. This allows cluster -administrators to set up identities and users manually, or using an external -process. Using this method requires you to manually provision users. -add:: Provisions a user with the identity's preferred user name. If a user -with that user name already exists, the identity is mapped to the existing user, -adding to any existing identity mappings for the user. Required when multiple -identity providers are configured that identify the same set of users and map to -the same user names. +claim:: The default value. Provisions a user with the identity's preferred user name. Fails if a user with that user name is already mapped to another identity. +lookup:: Looks up an existing identity, user identity mapping, and user, but does not automatically provision users or identities. This allows cluster administrators to set up identities and users manually, or using an external process. Using this method requires you to manually provision users. +add:: Provisions a user with the identity's preferred user name. If a user with that user name already exists, the identity is mapped to the existing user, adding to any existing identity mappings for the user. Required when multiple identity providers are configured that identify the same set of users and map to the same user names. |=== [NOTE] -When adding or changing identity providers, you can map identities from the new -provider to existing users by setting the `mappingMethod` parameter to -`add`. +When adding or changing identity providers, you can map identities from the new provider to existing users by setting the `mappingMethod` parameter to `add`. diff --git a/modules/managing-dedicated-administrators.adoc b/modules/managing-dedicated-administrators.adoc index d57de3d1636b..5f1902734547 100644 --- a/modules/managing-dedicated-administrators.adoc +++ b/modules/managing-dedicated-administrators.adoc @@ -4,10 +4,10 @@ :_mod-docs-content-type: PROCEDURE [id="managing-dedicated-administrators_{context}"] -= Managing {product-title} administrators += Manage {product-title} administrators [role="_abstract"] -Administrator roles are managed using a `cluster-admin` or `dedicated-admin` group on the cluster. Existing members of this group can edit membership through {cluster-manager-url}. +You can manage administrator roles by using the `cluster-admin` or `dedicated-admin` group on the cluster. Existing members of this group can edit membership through {cluster-manager-url}. .Procedure diff --git a/modules/osd-revoke-admin-privileges.adoc b/modules/osd-revoke-admin-privileges.adoc index 3fa1879d8ae2..c7b59e6e49be 100644 --- a/modules/osd-revoke-admin-privileges.adoc +++ b/modules/osd-revoke-admin-privileges.adoc @@ -5,7 +5,7 @@ :_mod-docs-content-type: PROCEDURE [id="osd-revoke-admin-privileges_{context}"] -= Revoking administrator privileges from a user += Revoke administrator privileges from a user [role="_abstract"] After you have granted `dedicated-admin` privileges to a user, you can revoke those privileges when they are no longer needed. @@ -23,8 +23,8 @@ After you have granted `dedicated-admin` privileges to a user, you can revoke th . Click the *Access control* tab. -. In the *Cluster Roles and Access* tab, select {kebab} next to a user and click *Delete*. +. In the *Cluster Roles and Access* tab, click {kebab} next to a user and click *Delete*. .Verification -* After revoking the privileges, the user is no longer listed as part of the `dedicated-admins` group under *Access control* -> *Cluster Roles and Access* on the {cluster-manager} page for your cluster. +* After revoking the privileges, the user is no longer listed as part of the `dedicated-admins` group under *Access control* > *Cluster Roles and Access* on the {cluster-manager} page for your cluster. diff --git a/modules/osd-revoke-user-access.adoc b/modules/osd-revoke-user-access.adoc index 2c583ef9bfd1..dd98fdfc9c3f 100644 --- a/modules/osd-revoke-user-access.adoc +++ b/modules/osd-revoke-user-access.adoc @@ -5,7 +5,7 @@ :_mod-docs-content-type: PROCEDURE [id="osd-revoke-user-access_{context}"] -= Revoking user access to a cluster += Revoke user access to a cluster [role="_abstract"] You can revoke cluster access from an identity provider user by removing them from your configured identity provider. @@ -28,4 +28,4 @@ You can configure different types of identity providers for your {product-title} .Verification -* After removing the user from your identity provider, the user cannot authenticate into the cluster. +* After removing the user from your identity provider, the user cannot authenticate to the cluster. diff --git a/modules/rosa-config-htpasswd-idp-cli-file.adoc b/modules/rosa-config-htpasswd-idp-cli-file.adoc index 36f69f51e173..ee5160cc46c4 100644 --- a/modules/rosa-config-htpasswd-idp-cli-file.adoc +++ b/modules/rosa-config-htpasswd-idp-cli-file.adoc @@ -14,7 +14,7 @@ ifeval::["{context}" == "rosa-config-identity-providers"] endif::[] [id="rosa-config-htpasswd-idp-cli-file_{context}"] -= Configuring an htpasswd identity provider with an htpasswd file += Configure an htpasswd identity provider with an htpasswd file [role="_abstract"] You can create an htpasswd identity provider (IDP) with the {rosa-cli-first} tool and a well-formed htpasswd file. @@ -25,7 +25,7 @@ You can create an htpasswd identity provider (IDP) with the {rosa-cli-first} too .Procedure -* Create a text file with a new row for each set of credentials with the username and password being colon separated like the following example: +* Create a text file with a new row for each set of credentials with the username and password being colon separated as in the following example: + [source,text] ---- diff --git a/modules/rosa-config-htpasswd-idp-cli.adoc b/modules/rosa-config-htpasswd-idp-cli.adoc index 40705955c003..0e807ab64eb4 100644 --- a/modules/rosa-config-htpasswd-idp-cli.adoc +++ b/modules/rosa-config-htpasswd-idp-cli.adoc @@ -4,7 +4,7 @@ :_mod-docs-content-type: PROCEDURE [id="rosa-config-htpasswd-idp-cli_{context}"] -= Configuring an htpasswd identity provider with the CLI += Configure an htpasswd identity provider with the CLI [role="_abstract"] You can create an htpasswd identity provider (IDP) with the {rosa-cli-first} tool. @@ -24,7 +24,7 @@ $ rosa create idp --type=htpasswd -c --users='user1:password1,us + [NOTE] ==== -The `--users` string value must be a comma separated list of `username:password,` within quotes like `"user1:password"` to create a user account with a name of `user1` and a password of `password`. The quotes prevent your password from disrupting the Bash commands. +The `--users` string value must be a comma-separated list of `username:password,` within quotes such as `"user1:password"` to create a user account with a name of `user1` and a password of `password`. The quotes prevent your password from disrupting the Bash commands. Passwords must include uppercase letters, lowercase letters, and numbers or symbols, specifically, ASCII-standard characters only. The password must be at least 14 characters. ==== \ No newline at end of file diff --git a/modules/sd-config-htpasswd-idp-cli.adoc b/modules/sd-config-htpasswd-idp-cli.adoc index 8158ece8cf3b..33164287a849 100644 --- a/modules/sd-config-htpasswd-idp-cli.adoc +++ b/modules/sd-config-htpasswd-idp-cli.adoc @@ -4,14 +4,14 @@ :_mod-docs-content-type: PROCEDURE [id="sd-config-htpasswd-idp-cli_{context}"] -= Configuring an htpasswd identity provider with the CLI += Configure an htpasswd identity provider with the CLI [role="_abstract"] -You can create an htpasswd identity provider (IDP) with the OCM CLI (`ocm`) tool. +You can create an htpasswd identity provider (IDP) with the {cluster-manager} CLI (`ocm`) tool. .Prerequisites -* You have installed and configured the latest version of the OCM CLI (`ocm`). +* You have installed and configured the latest version of the {cluster-manager} CLI (`ocm`). .Procedure @@ -24,7 +24,7 @@ $ ocm create idp --type htpasswd --cluster --name --us + [NOTE] ==== -You must include the password within quotes like `'password'` to prevent your password from disrupting the Bash commands. +You must include the password within quotes such as `'password'` to prevent your password from disrupting the Bash commands. Passwords must include uppercase letters, lowercase letters, and numbers or symbols, specifically, ASCII-standard characters only. The password must be at least 14 characters. ==== \ No newline at end of file diff --git a/modules/setting-up-an-aws-iam-role-a-service-account.adoc b/modules/setting-up-an-aws-iam-role-a-service-account.adoc index 55282bdebf7b..2b358ede24e8 100644 --- a/modules/setting-up-an-aws-iam-role-a-service-account.adoc +++ b/modules/setting-up-an-aws-iam-role-a-service-account.adoc @@ -4,7 +4,7 @@ :_mod-docs-content-type: PROCEDURE [id="setting-up-an-aws-iam-role-a-service-account_{context}"] -= Setting up an AWS IAM role for a service account += Set up an AWS IAM role for a service account [role="_abstract"] You can create an AWS Identity and Access Management (IAM) role to be assumed by a service account in your {product-title} cluster that contains the permissions required by your service account to run AWS SDK operations in a pod. diff --git a/modules/understanding-admin-roles.adoc b/modules/understanding-admin-roles.adoc index 198a3f217211..ed70415b6371 100644 --- a/modules/understanding-admin-roles.adoc +++ b/modules/understanding-admin-roles.adoc @@ -4,16 +4,16 @@ :_mod-docs-content-type: CONCEPT [id="understanding-admin-roles_{context}"] -= Understanding administration roles += Administration roles [role="_abstract"] -As an administrator of an {product-title} cluster, you have access to the `cluster-admin` and `dedicated-admin` roles. These roles have different permissions and access levels that allow you to manage and configure your cluster effectively. Understanding the differences between these roles can help you assign the appropriate permissions to users and manage your cluster more efficiently. +As an administrator of an {product-title} cluster, you have access to the `cluster-admin` and `dedicated-admin` roles. These roles have different permissions and access levels for managing and configuring your cluster. -== The cluster-admin role -As an administrator of an {product-title} cluster with Customer Cloud Subscriptions (CCS), you have access to the `cluster-admin` role. The user who created the cluster can add the `cluster-admin` user role to an account to have the maximum administrator privileges. These privileges are not automatically assigned to your user account when you create the cluster. While logged in to an account with the cluster-admin role, users have mostly unrestricted access to control and configure the cluster. There are some configurations that are blocked with webhooks to prevent destabilizing the cluster, or because they are managed in {cluster-manager-url} and any in-cluster changes would be overwritten. Usage of the cluster-admin role is subject to the restrictions listed in your Appendix 4 agreement with Red Hat. As a best practice, limit the number of `cluster-admin` users to as few as possible. +The `cluster-admin` role:: +As an administrator of an {product-title} cluster with Customer Cloud Subscriptions (CCS), you have access to the `cluster-admin` role. The user who created the cluster can add the `cluster-admin` user role to an account to have the maximum administrator privileges. These privileges are not automatically assigned to your user account when you create the cluster. While logged in to an account with the `cluster-admin` role, users have mostly unrestricted access to control and configure the cluster. There are some configurations that are blocked with webhooks to prevent destabilizing the cluster, or because they are managed in {cluster-manager-url} and any in-cluster changes would be overwritten. Usage of the `cluster-admin` role is subject to the restrictions listed in your Appendix 4 agreement with Red Hat. As a best practice, limit the number of `cluster-admin` users to as few as possible. -== The dedicated-admin role -As an administrator of an {product-title} cluster, your account has additional permissions and access to all user-created projects in your organization’s cluster. While logged in to an account with the `dedicated-admin` role, the developer CLI commands (under the `oc` command) allow you increased visibility and management capabilities over objects across projects, while the administrator CLI commands (under the `oc adm` command) allow you to complete additional operations. +The `dedicated-admin` role:: +As an administrator of an {product-title} cluster, your account has additional permissions and access to all user-created projects in your organization's cluster. While logged in to an account with the `dedicated-admin` role, you can use the developer CLI commands (under the `oc` command) for increased visibility and management capabilities over objects across projects, while the administrator CLI commands (under the `oc adm` command) enable you to complete additional operations. [NOTE] ==== diff --git a/modules/understanding-idp.adoc b/modules/understanding-idp.adoc index 0af730b9212e..af05f1ccf5b3 100644 --- a/modules/understanding-idp.adoc +++ b/modules/understanding-idp.adoc @@ -5,14 +5,10 @@ :_mod-docs-content-type: CONCEPT [id="understanding-idp_{context}"] -= Understanding identity providers += Supported identity providers [role="_abstract"] -{product-title} includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. As an administrator, you can configure OAuth to specify an identity provider after you install your cluster. Configuring identity providers allows users to log in and access the cluster. - -[id="understanding-idp-supported_{context}"] -== Supported identity providers -// This section is sourced from authentication/understanding-identity-provider.adoc +{product-title} includes a built-in OAuth server. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. As an administrator, you can configure OAuth to specify an identity provider after you install your cluster. After you configure identity providers, users can log in and access the cluster. You can configure the following types of identity providers: @@ -29,7 +25,7 @@ You can configure the following types of identity providers: |Configure a GitLab identity provider to use GitLab.com or any other GitLab instance as an identity provider. |Google -|Configure a Google identity provider using Google's OpenID Connect integration. +|Configure a Google identity provider by using Google OpenID Connect integration. |LDAP |Configure an LDAP identity provider to validate usernames and passwords against an LDAPv3 server, using simple bind authentication. diff --git a/modules/verifying-the-assumed-iam-role-in-your-pod.adoc b/modules/verifying-the-assumed-iam-role-in-your-pod.adoc index 4b97ef5ad553..f1e2c36a97a5 100644 --- a/modules/verifying-the-assumed-iam-role-in-your-pod.adoc +++ b/modules/verifying-the-assumed-iam-role-in-your-pod.adoc @@ -4,10 +4,10 @@ :_mod-docs-content-type: PROCEDURE [id="verifying-the-assumed-iam-role-in-your-pod_{context}"] -= Verifying the assumed IAM role in your pod += Verify the assumed IAM role in your pod [role="_abstract"] -After deploying an `awsboto3sdk` pod in your project, verify that the pod identity webhook has mutated the pod and check that the required AWS environment variables, volume mount, and OIDC token volume are present within the pod. +After deploying an `awsboto3sdk` pod in your project, verify that the pod identity webhook has mutated the pod and check that the required AWS environment variables, volume mount, and OpenID Connect (OIDC) token volume are present within the pod. You can also verify that the service account assumes the AWS Identity and Access Management (IAM) role for your AWS account when you run AWS SDK operations in the pod. @@ -15,7 +15,7 @@ You can also verify that the service account assumes the AWS Identity and Access * You have created an AWS IAM role for your service account. For more information, see _Setting up an AWS IAM role for a service account_. * You have access to a {product-title} cluster that uses the AWS Security Token Service (STS). Admin-level user privileges are not required. -* You have installed the OpenShift CLI (`oc`). +* You have installed the {oc-first}. * You have created a service account in your project that includes an `eks.amazonaws.com/role-arn` annotation that references the Amazon Resource Name (ARN) for the IAM role that you want the service account to assume. * You have deployed a pod in your user-defined project that includes an AWS SDK. The pod references the service account that uses the pod identity webhook to assume the AWS IAM role required to run the AWS SDK operations. For detailed steps, see _Deploying a pod that includes an AWS SDK_. + diff --git a/rosa_learning/creating_cluster_workshop/learning-getting-started-idp.adoc b/rosa_learning/creating_cluster_workshop/learning-getting-started-idp.adoc index b8bbfebe23dd..6713c791116b 100644 --- a/rosa_learning/creating_cluster_workshop/learning-getting-started-idp.adoc +++ b/rosa_learning/creating_cluster_workshop/learning-getting-started-idp.adoc @@ -17,5 +17,5 @@ include::modules/learning-getting-idp-granting-access.adoc[leveloffset=+1] [role="_additional-resources"] == Additional resources -* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/latest/html-single/authentication_and_authorization/index#understanding-idp-supported_sd-configuring-identity-providers[IDPs supported by {product-title}] +* link:https://docs.redhat.com/en/documentation/red_hat_openshift_service_on_aws/latest/html-single/authentication_and_authorization/index#understanding-idp_sd-configuring-identity-providers[IDPs supported by {product-title}]