:_mod-docs-content-type: ASSEMBLY
[id="osdk-cco-aws-sts"]
= CCO-based workflow for OLM-managed Operators with AWS STS
include::_attributes/common-attributes.adoc[]
:context: osdk-cco-aws-sts

toc::[]

When an {product-title} cluster running on AWS is in Security Token Service (STS) mode, it means the cluster is utilizing features of AWS and {product-title} to use IAM roles at an application level. STS enables applications to provide a JSON Web Token (JWT) that can assume an IAM role.

The JWT includes an Amazon Resource Name (ARN) for the `sts:AssumeRoleWithWebIdentity` IAM action to allow temporarily-granted permission for the service account. The JWT contains the signing keys for the `ProjectedServiceAccountToken` that AWS IAM can validate. The service account token itself, which is signed, is used as the JWT required for assuming the AWS role.

The Cloud Credential Operator (CCO) is a cluster Operator installed by default in {product-title} clusters running on cloud providers. For the purposes of STS, the CCO provides the following functions:

* Detects when it is running on an STS-enabled cluster
* Checks the `CredentialsRequest` object for the presence of fields that provide the required information for granting Operators access to AWS resources

The CCO performs this detection even when in manual mode. When properly configured, the CCO projects a `Secret` object with the required access information into the Operator namespace.

Starting in {product-title} 4.14, the CCO can semi-automate this task through an expanded use of `CredentialsRequest` objects, which can request the creation of `Secrets` that contain the information required for STS workflows. Users can provide a role ARN when installing the Operator from either the web console or CLI.

[NOTE]
====
Subscriptions with automatic approvals for updates are not recommended because there might be permission changes to make before updating. Subscriptions with manual approvals for updates ensure that administrators have the opportunity to verify the permissions of the later version, take any necessary steps, and then update.
====

As an Operator author preparing an Operator for use alongside the updated CCO in {product-title} 4.14 or later, you should instruct users and add code to handle the divergence from earlier CCO versions, in addition to handling STS token authentication (if your Operator is not already STS-enabled). The recommended method is to provide a `CredentialsRequest` object with the correctly filled {sts-short} fields and let the CCO create the `Secret` for you.

[IMPORTANT]
====
If you plan to support {product-title} clusters earlier than version 4.14, consider providing users with instructions on how to manually create a secret with the STS-enabling information by using the CCO utility (`ccoctl`). Earlier CCO versions are unaware of STS mode on the cluster and cannot create secrets for you.

Your code should check for secrets that never appear and warn users to follow the fallback instructions you have provided. For more information, see the "Alternative method" subsection.
====

[role="_additional-resources"]
.Additional resources

* xref:../../../authentication/managing_cloud_provider_credentials/cco-short-term-creds.adoc#cco-short-term-creds-aws-olm_cco-short-term-creds[OLM-managed Operator support for authentication with AWS STS]
* xref:../../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-from-software-catalog-using-web-console_olm-adding-operators-to-a-cluster[Installing from OperatorHub using the web console]
* xref:../../../operators/admin/olm-adding-operators-to-cluster.adoc#olm-installing-operator-from-software-catalog-using-cli_olm-adding-operators-to-a-cluster[Installing from OperatorHub using the CLI]

include::modules/osdk-cco-aws-sts-enabling.adoc[leveloffset=+1]

include::modules/osdk-cco-aws-sts-role.adoc[leveloffset=+1]

include::modules/osdk-cco-aws-sts-tshooting.adoc[leveloffset=+1]

include::modules/osdk-cco-aws-sts-alt.adoc[leveloffset=+1]
