Merge pull request #36660 from liggitt/scrape-secrets

Update service account token documentation
This commit is contained in:
Kubernetes Prow Robot 2022-09-10 16:31:23 -07:00 committed by GitHub
commit d057687f6f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 14 additions and 47 deletions

View File

@ -244,7 +244,6 @@ kubectl get secrets
``` ```
``` ```
NAME TYPE DATA AGE NAME TYPE DATA AGE
default-token-il9rc kubernetes.io/service-account-token 1 1d
nginxsecret kubernetes.io/tls 2 1m nginxsecret kubernetes.io/tls 2 1m
``` ```
And also the configmap: And also the configmap:
@ -291,7 +290,6 @@ kubectl get secrets
``` ```
``` ```
NAME TYPE DATA AGE NAME TYPE DATA AGE
default-token-il9rc kubernetes.io/service-account-token 1 1d
nginxsecret kubernetes.io/tls 2 1m nginxsecret kubernetes.io/tls 2 1m
``` ```

View File

@ -210,65 +210,42 @@ Service account bearer tokens are perfectly valid to use outside the cluster and
can be used to create identities for long standing jobs that wish to talk to the can be used to create identities for long standing jobs that wish to talk to the
Kubernetes API. To manually create a service account, use the `kubectl create Kubernetes API. To manually create a service account, use the `kubectl create
serviceaccount (NAME)` command. This creates a service account in the current serviceaccount (NAME)` command. This creates a service account in the current
namespace and an associated secret. namespace.
```bash ```bash
kubectl create serviceaccount jenkins kubectl create serviceaccount jenkins
``` ```
```none ```none
serviceaccount "jenkins" created serviceaccount/jenkins created
``` ```
Check an associated secret: Create an associated token:
```bash ```bash
kubectl get serviceaccounts jenkins -o yaml kubectl create token jenkins
``` ```
```yaml ```none
apiVersion: v1 eyJhbGciOiJSUzI1NiIsImtp...
kind: ServiceAccount
metadata:
# ...
secrets:
- name: jenkins-token-1yvwg
``` ```
The created secret holds the public CA of the API server and a signed JSON Web The created token is a signed JSON Web Token (JWT).
Token (JWT).
```bash
kubectl get secret jenkins-token-1yvwg -o yaml
```
```yaml
apiVersion: v1
data:
ca.crt: (APISERVER'S CA BASE64 ENCODED)
namespace: ZGVmYXVsdA==
token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
# ...
type: kubernetes.io/service-account-token
```
{{< note >}}
Values are base64 encoded because secrets are always base64 encoded.
{{< /note >}}
The signed JWT can be used as a bearer token to authenticate as the given service The signed JWT can be used as a bearer token to authenticate as the given service
account. See [above](#putting-a-bearer-token-in-a-request) for how the token is included account. See [above](#putting-a-bearer-token-in-a-request) for how the token is included
in a request. Normally these secrets are mounted into pods for in-cluster access to in a request. Normally these tokens are mounted into pods for in-cluster access to
the API server, but can be used from outside the cluster as well. the API server, but can be used from outside the cluster as well.
Service accounts authenticate with the username `system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`, Service accounts authenticate with the username `system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)`,
and are assigned to the groups `system:serviceaccounts` and `system:serviceaccounts:(NAMESPACE)`. and are assigned to the groups `system:serviceaccounts` and `system:serviceaccounts:(NAMESPACE)`.
WARNING: Because service account tokens are stored in secrets, any user with {{< warning >}}
read access to those secrets can authenticate as the service account. Be cautious Because service account tokens can also be stored in Secret API objects, any user with
when granting permissions to service accounts and read capabilities for secrets. write access to Secrets can request a token, and any user with read access to those
Secrets can authenticate as the service account. Be cautious when granting permissions
to service accounts and read or write capabilities for Secrets.
{{< /warning >}}
### OpenID Connect Tokens ### OpenID Connect Tokens

View File

@ -115,12 +115,8 @@ metadata:
namespace: default namespace: default
resourceVersion: "272500" resourceVersion: "272500"
uid: 721ab723-13bc-11e5-aec2-42010af0021e uid: 721ab723-13bc-11e5-aec2-42010af0021e
secrets:
- name: build-robot-token-bvbk5
``` ```
then you will see that a token has automatically been created and is referenced by the service account.
You may use authorization plugins to [set permissions on service accounts](/docs/reference/access-authn-authz/rbac/#service-account-permissions). You may use authorization plugins to [set permissions on service accounts](/docs/reference/access-authn-authz/rbac/#service-account-permissions).
To use a non-default service account, set the `spec.serviceAccountName` To use a non-default service account, set the `spec.serviceAccountName`
@ -233,8 +229,6 @@ metadata:
namespace: default namespace: default
resourceVersion: "243024" resourceVersion: "243024"
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
secrets:
- name: default-token-uudge
``` ```
Using your editor of choice (for example `vi`), open the `sa.yaml` file, delete line with key `resourceVersion`, add lines with `imagePullSecrets:` and save. Using your editor of choice (for example `vi`), open the `sa.yaml` file, delete line with key `resourceVersion`, add lines with `imagePullSecrets:` and save.
@ -249,8 +243,6 @@ metadata:
name: default name: default
namespace: default namespace: default
uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6 uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
secrets:
- name: default-token-uudge
imagePullSecrets: imagePullSecrets:
- name: myregistrykey - name: myregistrykey
``` ```