This glosary is intended to catalogue and define all terms used in our documentation which may not be evident to new users of the operator.
By extension of this glossary, we may also use terms from the following glossaries:
AWS Organizations provide a "unified bill" under a single account - the Payer Account. Sub accounts are created under this Payer Account, which is the highest-level account in this organization. Throughout this documentation, there is the expectation that users of the operator will have an IAM user with credentials on each Payer Account, which has AssumeRole Permissions as administrator into each of these sub-accounts.
We support 2 types of clusters:
- Red Hat Managed Cluster: Standard OpenShift Dedicated clusters are deployed into their own cloud infrastructure accounts, each owned by Red Hat. Red Hat is responsible for this account. From this account, only Red Hat managed clusters will be visible, in other words, CCS/BYOC clusters will not.
- CCS / BYOC: CCS (Customer Cloud Subscriptions) or BYOC (Bring your Own Cluster) clusters are those which belong to customers’ personal AWS accounts, as opposed to being owned by Red Hat. Therefore, for CCS we are provisioning a cluster in an account provided by the customer. For CCS clusters, we are going to find multiple clusters per account.
AWS Security Token Service (AWS STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate (federated users).
Trust relationships/Trust Policies are then configured between the IAM users and the IAM roles. This policy defines which principals can assume the role, and under which conditions. This is sometimes referred to as a resource-based policy for the IAM role.
Returns a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to. These temporary credentials consist of an access key ID, a secret access key, and a security token. Typically, you use Assume Role within your account or for cross-account access.
Using AWS Assume Role Chaining, a Jump Role is an intermediary role that sits between a given IAM user and a customer's access role, providing a single point of entry.
A role inside the cluster's account that we assume to perform tasks.
Amazon Resource Names (ARN) uniquely identify AWS resources. AWS require an ARN when you need to specify a resource unambiguously across all of AWS, such as in IAM policies, Amazon Relational Database Service (Amazon RDS) tags, and API calls.
Each CR defines an AWS Role. The controller converts the config into JSON, and verifies that it can be created in AWS properly by attempting to create the role. It then deletes it immediately afterward. View example Federated Role CRs.
Represents a request for an instance of an AWS Role. User provides the desired role and an ARN referencing an IAM user in an external AWS Account. The controller creates the needed Policies and the Role in the cluster’s AWS Account with the provided ARN as the principal (gives permission to that ARN to use the role)