Skip to content

Commit eb08487

Browse files
authored
Merge pull request #64331 from bhardesty/osdocs-7640-sts-oidc-provider
OSDOCS-7640: Doc how service accounts assume AWS IAM roles
2 parents 7dcdea0 + 8244fc1 commit eb08487

File tree

6 files changed

+68
-8
lines changed

6 files changed

+68
-8
lines changed

_topic_maps/_topic_map_osd.yml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -50,8 +50,8 @@ Topics:
5050
File: policy-responsibility-matrix
5151
- Name: Understanding process and security for OpenShift Dedicated
5252
File: policy-process-security
53-
# - Name: SRE and service account access
54-
# File: osd-sre-access
53+
# - Name: SRE and service account access
54+
# File: osd-sre-access
5555
- Name: About availability for OpenShift Dedicated
5656
File: policy-understand-availability
5757
- Name: Update life cycle

authentication/assuming-an-aws-iam-role-for-a-service-account.adoc

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -11,11 +11,12 @@ toc::[]
1111

1212
[role="_abstract"]
1313
ifdef::openshift-rosa[]
14-
{product-title} clusters that use the AWS Security Token Service (STS) include a pod identity webhook for use with pods that run in user-defined projects.
14+
In {product-title} clusters that use the AWS Security Token Service (STS), the OpenShift API server can be enabled to project signed service account tokens that can be used to assume an AWS Identity and Access Management (IAM) role in a pod. If the assumed IAM role has the required AWS permissions, the pods can authenticate against the AWS API using temporary STS credentials to perform AWS operations.
1515
endif::openshift-rosa[]
1616

17-
You can use the pod identity webhook to enable a service account to automatically assume an AWS Identity and Access Management (IAM) role in your own pods. If the assumed IAM role has the required AWS permissions, the pods can run AWS SDK operations by using temporary STS credentials.
17+
You can use the pod identity webhook to project service account tokens to assume an AWS Identity and Access Management (IAM) role for your own workloads. If the assumed IAM role has the required AWS permissions, the pods can run AWS SDK operations by using temporary STS credentials.
1818

19+
include::modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc[leveloffset=+1]
1920
include::modules/understanding-pod-identity-webhook-workflow-in-user-defined-projects.adoc[leveloffset=+1]
2021
include::modules/assuming-an-aws-iam-role-in-your-own-pods.adoc[leveloffset=+1]
2122
include::modules/setting-up-an-aws-iam-role-a-service-account.adoc[leveloffset=+2]
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * authentication/assuming-an-aws-iam-role-for-a-service-account.adoc
4+
// * rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc
5+
6+
:_content-type: CONCEPT
7+
[id="how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects_{context}"]
8+
= How service accounts assume AWS IAM roles in SRE owned projects
9+
10+
When you install a {product-title} cluster that uses the AWS Security Token Service (STS), cluster-specific Operator AWS Identity and Access Management (IAM) roles are created. These IAM roles permit the {product-title} cluster Operators to run core OpenShift functionality.
11+
12+
Cluster Operators use service accounts to assume IAM roles. When a service account assumes an IAM role, temporary 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.
13+
14+
[discrete]
15+
[id="workflow-for-assuming-aws-iam-roles-in-sre-owned-projects_{context}"]
16+
== Workflow for assuming AWS IAM roles in SRE owned projects
17+
18+
// The following diagram illustrates the workflow by which the service accounts for cluster Operators assume IAM roles:
19+
//
20+
// .Workflow for assuming AWS IAM roles in SRE-owned projects
21+
// TODO: Add diagram.
22+
23+
The workflow has the following stages:
24+
25+
. Within each project that a cluster Operator runs, the Operator's deployment spec has a volume mount for the projected service account token, and a secret containing AWS credential configuration for the pod. The token is audience-bound and time-bound. Every hour, {product-title} generates a new token, and the AWS SDK reads the mounted secret containing the AWS credential configuration. This configuration has a path to the mounted token and the AWS IAM Role ARN. The secret's credential configuration includes the following:
26+
27+
** An `$AWS_ARN_ROLE` variable that has the ARN for the IAM role that has the permissions required to run AWS SDK operations.
28+
29+
** An `$AWS_WEB_IDENTITY_TOKEN_FILE` variable that has the full path in the pod to the OpenID Connect (OIDC) token for the service account. The full path is `/var/run/secrets/openshift/serviceaccount/token`.
30+
31+
. When a cluster Operator needs to assume an AWS IAM role to access an AWS service (such as EC2), the AWS SDK client code running on the Operator invokes the `AssumeRoleWithWebIdentity` API call.
32+
33+
. The OIDC token is passed from the pod to the OIDC provider. The provider authenticates the service account identity if the following requirements are met:
34+
35+
** The identity signature is valid and signed by the private key.
36+
37+
** The `sts.amazonaws.com` audience is listed in the OIDC token and matches the audience configured in the OIDC provider.
38+
+
39+
[NOTE]
40+
====
41+
In {product-title} with STS clusters, the OIDC provider is created during install and set as the service account issuer by default. The `sts.amazonaws.com` audience is set by default in the OIDC provider.
42+
====
43+
44+
** The OIDC token has not expired.
45+
46+
** The issuer value in the token has the URL for the OIDC provider.
47+
48+
. If the project and service account are in the scope of the trust policy for the IAM role that is being assumed, then authorization succeeds.
49+
50+
. After successful authentication and authorization, temporary AWS STS credentials in the form of an AWS access token, secret key, and session token are passed to the pod for use by the service account. By using the credentials, the service account is temporarily granted the AWS permissions enabled in the IAM role.
51+
52+
. When the cluster Operator runs, the Operator that is using the AWS SDK in the pod consumes the secret that has the path to the projected service account and AWS IAM Role ARN to authenticate against the OIDC provider. The OIDC provider returns temporary STS credentials for authentication against the AWS API.

modules/understanding-pod-identity-webhook-workflow-in-user-defined-projects.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,8 +3,8 @@
33
// * authentication/assuming-an-aws-iam-role-for-a-service-account.adoc
44

55
:_content-type: CONCEPT
6-
[id="understanding-pod-identity-webhook-workflow-in-user-defined-projects_{context}"]
7-
= Understanding the pod identity webhook workflow in user-defined projects
6+
[id="how-service-accounts-assume-aws-iam-roles-in-user-defined-projects_{context}"]
7+
= How service accounts assume AWS IAM roles in user-defined projects
88

99
When you install a {product-title} cluster
1010
ifdef::openshift-rosa[]
Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
1-
////
21
:_content-type: ASSEMBLY
32
include::_attributes/attributes-openshift-dedicated.adoc[]
43
:context: osd-sre-access
54
[id="osd-sre-access"]
65
= SRE and service account access
7-
////
6+
7+
include::modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc[leveloffset=+1]

rosa_architecture/rosa_policy_service_definition/rosa-sre-access.adoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,3 +8,10 @@ Red Hat site reliability engineering (SRE) access to ROSA clusters is outlined t
88

99
include::modules/rosa-policy-identity-access-management.adoc[leveloffset=+1]
1010
include::modules/rosa-sre-access-privatelink-vpc.adoc[leveloffset=+1]
11+
include::modules/how-service-accounts-assume-aws-iam-roles-in-sre-owned-projects.adoc[leveloffset=+1]
12+
13+
[role="_additional-resources"]
14+
.Additional resources
15+
16+
* For more information about the AWS IAM roles used by the cluster Operators, see xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-operator-roles_rosa-sts-about-iam-resources[Cluster-specific Operator IAM role reference].
17+
* For more information about the policies and permissions that the cluster Operators require, see xref:../../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies-creation-methods_rosa-sts-about-iam-resources[Methods of account-wide role creation].

0 commit comments

Comments
 (0)