Skip to content

Commit

Permalink
OSDOCS#10143: Updating that SA API token secrets are no longer automa…
Browse files Browse the repository at this point in the history
…tically generated
  • Loading branch information
bergerhoffer committed Apr 29, 2024
1 parent 28db2f8 commit c2dce5c
Show file tree
Hide file tree
Showing 5 changed files with 23 additions and 45 deletions.
6 changes: 0 additions & 6 deletions authentication/using-service-accounts-in-applications.adoc
Expand Up @@ -12,12 +12,6 @@ include::modules/service-accounts-default.adoc[leveloffset=+1]

include::modules/service-account-auto-secret-removed.adoc[leveloffset=+2]

.Additional resources

* For information about requesting bound service account tokens, see xref:../authentication/bound-service-account-tokens.adoc#bound-sa-tokens-configuring_bound-service-account-tokens[Configuring bound service account tokens using volume projection].
* For information about creating a service account token secret, see xref:../nodes/pods/nodes-pods-secrets.adoc#nodes-pods-secrets-creating-sa_nodes-pods-secrets[Creating a service account token secret].
include::modules/service-accounts-creating.adoc[leveloffset=+1]

// include::modules/service-accounts-using-credentials-inside-a-container.adoc[leveloffset=+1]
4 changes: 2 additions & 2 deletions modules/cluster-image-registry-operator.adoc
Expand Up @@ -34,11 +34,11 @@ If insufficient information is available to define a complete `image-registry` r
The Cluster Image Registry Operator runs in the `openshift-image-registry` namespace and it also manages the registry instance in that location. All configuration and workload resources for the registry reside in that namespace.

ifdef::cluster-caps[]
In order to integrate the image registry into the cluster's user authentication and authorization system, a service account token secret and an image pull secret are generated for each service account in the cluster.
In order to integrate the image registry into the cluster's user authentication and authorization system, a dockercfg image pull secret is generated for each service account in the cluster.

[IMPORTANT]
====
If you disable the `ImageRegistry` capability or if you disable the integrated {product-registry} in the Cluster Image Registry Operator's configuration, the service account token secret and image pull secret are not generated for each service account.
If you disable the `ImageRegistry` capability or if you disable the integrated {product-registry} in the Cluster Image Registry Operator's configuration, the dockercfg image pull secret is not generated for each service account.
====

If you disable the `ImageRegistry` capability, you can reduce the overall resource footprint of {product-title} in resource-constrained environments. Depending on your deployment, you can disable this component if you do not need it.
Expand Down
20 changes: 13 additions & 7 deletions modules/nodes-pods-secrets-creating-sa.adoc
Expand Up @@ -4,24 +4,30 @@

:_mod-docs-content-type: PROCEDURE
[id="nodes-pods-secrets-creating-sa_{context}"]
= Creating a service account token secret
= Creating a legacy service account token secret

As an administrator, you can create a service account token secret, which allows you to distribute a service account token to applications that must authenticate to the API.
As an administrator, you can create a legacy service account token secret, which allows you to distribute a service account token to applications that must authenticate to the API.

[NOTE]
[WARNING]
====
It is recommended to obtain bound service account tokens using the TokenRequest API instead of using service account token secrets. The tokens obtained from the TokenRequest API are more secure than the tokens stored in secrets, because they have a bounded lifetime and are not readable by other API clients.
It is recommended to obtain bound service account tokens using the TokenRequest API instead of using legacy service account token secrets. You should create a service account token secret only if you cannot use the TokenRequest API and if the security exposure of a non-expiring token in a readable API object is acceptable to you.
You should create a service account token secret only if you cannot use the TokenRequest API and if the security exposure of a non-expiring token in a readable API object is acceptable to you.
Bound service account tokens are more secure than service account token secrets for the following reasons:
See the Additional resources section that follows for information on creating bound service account tokens.
* Bound service account tokens have a bounded lifetime.
* Bound service account tokens contain audiences.
* Bound service account tokens can be bound to pods or secrets and the bound tokens are invalidated when the bound object is removed.
Workloads are automatically injected with a projected volume to obtain a bound service account token. If your workload needs an additional service account token, add an additional projected volume in your workload manifest.
For more information, see "Configuring bound service account tokens using volume projection".
====

.Procedure

. Create a `Secret` object in a YAML file on a control plane node:
+
.Example `secret` object:
.Example `Secret` object
[source,yaml]
----
apiVersion: v1
Expand Down
29 changes: 7 additions & 22 deletions modules/service-account-auto-secret-removed.adoc
Expand Up @@ -5,37 +5,22 @@

:_mod-docs-content-type: CONCEPT
[id="auto-generated-sa-token-secrets_{context}"]
= Automatically generated secrets
= Automatically generated image pull secrets

By default, {product-title} creates the following secrets for each service account:
By default, {product-title} creates a docker configuration image pull secret for each service account.

* A dockercfg image pull secret
* A service account token secret
+
[NOTE]
====
Prior to {product-title} 4.11, a second service account token secret was generated when a service account was created. This service account token secret was used to access the Kubernetes API.
Prior to {product-title} 4.16, a long-lived service account API token secret was also generated for each service account that was created. Starting with {product-title} 4.16, this service account API token secret is no longer created.
Starting with {product-title} 4.11, this second service account token secret is no longer created. This is because the `LegacyServiceAccountTokenNoAutoGeneration` upstream Kubernetes feature gate was enabled, which stops the automatic generation of secret-based service account tokens to access the Kubernetes API.

After upgrading to {product-version}, any existing service account token secrets are not deleted and continue to function.
After upgrading to {product-version}, any existing long-lived service account API token secrets are not deleted and will continue to function. For information about detecting long-lived API tokens that are in use in your cluster or deleting them if they are not needed, see the Red Hat Knowledgebase article link:https://access.redhat.com/articles/7058801[Long-lived service account API tokens in OpenShift Container Platform].
====

This service account token secret and docker configuration image pull secret are necessary to integrate the {product-registry} into the cluster's user authentication and authorization system.
This docker configuration image pull secret is necessary to integrate the {product-registry} into the cluster's user authentication and authorization system.

However, if you do not enable the `ImageRegistry` capability or if you disable the integrated {product-registry} in the Cluster Image Registry Operator's configuration, these secrets are not generated for each service account.
However, if you do not enable the `ImageRegistry` capability or if you disable the integrated {product-registry} in the Cluster Image Registry Operator's configuration, a dockercfg secret is not generated for each service account.

[WARNING]
====
Do not rely on these automatically generated secrets for your own use; they might be removed in a future {product-title} release.
Do not rely on these automatically generated image pull secrets for your own use; they might be removed in a future {product-title} release.
====

Workloads are automatically injected with a projected volume to obtain a bound service account token. If your workload needs an additional service account token, add an additional projected volume in your workload manifest. Bound service account tokens are more secure than service account token secrets for the following reasons:

* Bound service account tokens have a bounded lifetime.
* Bound service account tokens contain audiences.
* Bound service account tokens can be bound to pods or secrets and the bound tokens are invalidated when the bound object is removed.
For more information, see _Configuring bound service account tokens using volume projection_.

You can also manually create a service account token secret to obtain a token, if the security exposure of a non-expiring token in a readable API object is acceptable to you. For more information, see _Creating a service account token secret_.
9 changes: 1 addition & 8 deletions nodes/pods/nodes-pods-secrets.adoc
Expand Up @@ -14,13 +14,6 @@ include::modules/nodes-pods-secrets-about.adoc[leveloffset=+1]

include::modules/service-account-auto-secret-removed.adoc[leveloffset=+2]

.Additional resources

ifndef::openshift-rosa,openshift-dedicated[]
* For information about requesting bound service account tokens, see xref:../../authentication/bound-service-account-tokens.adoc#bound-sa-tokens-configuring_bound-service-account-tokens[Using bound service account tokens]
endif::openshift-rosa,openshift-dedicated[]
* For information about creating a service account token secret, see xref:../../nodes/pods/nodes-pods-secrets.doc#nodes-pods-secrets-creating-sa_nodes-pods-secrets[Creating a service account token secret].

include::modules/nodes-pods-secrets-creating.adoc[leveloffset=+1]

include::modules/nodes-pods-secrets-creating-opaque.adoc[leveloffset=+2]
Expand All @@ -39,7 +32,7 @@ include::modules/nodes-pods-secrets-creating-sa.adoc[leveloffset=+2]
ifndef::openshift-rosa,openshift-dedicated[]

* For information on requesting bound service account tokens, see xref:../../authentication/bound-service-account-tokens.adoc#bound-sa-tokens-configuring_bound-service-account-tokens[Using bound service account tokens]
* For information on requesting bound service account tokens, see xref:../../authentication/bound-service-account-tokens.adoc#bound-sa-tokens-configuring_bound-service-account-tokens[Configuring bound service account tokens using volume projection].
* For information on creating service accounts, see xref:../../authentication/understanding-and-creating-service-accounts.adoc#understanding-and-creating-service-accounts[Understanding and creating service accounts].
endif::openshift-rosa,openshift-dedicated[]
Expand Down

0 comments on commit c2dce5c

Please sign in to comment.