Difference between revisions of "Kubernetes Authentication"
Jump to navigation
Jump to search
↑ https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes
| Line 1: | Line 1: | ||
https://kubernetes.io/docs/reference/access-authn-authz/authentication/ | https://kubernetes.io/docs/reference/access-authn-authz/authentication/ | ||
| + | == Accounts == | ||
* [[Service accounts]] are users managed by the Kubernetes API. They are bound to specific [[namespaces]], and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as [[Secrets]], which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API. | * [[Service accounts]] are users managed by the Kubernetes API. They are bound to specific [[namespaces]], and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as [[Secrets]], which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API. | ||
* [[Users]]: "normal" user accounts cannot be added via an API call, any user that presents a valid [[certificate]] signed by the cluster's [[certificate authority]] (CA) is considered authenticated.<ref>https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes</ref>. Kubernetes determines the username from the common name field in the <code>'subject'</code> of the cert (e.g., <code>"/CN=your-user"</code>). | * [[Users]]: "normal" user accounts cannot be added via an API call, any user that presents a valid [[certificate]] signed by the cluster's [[certificate authority]] (CA) is considered authenticated.<ref>https://kubernetes.io/docs/reference/access-authn-authz/authentication/#users-in-kubernetes</ref>. Kubernetes determines the username from the common name field in the <code>'subject'</code> of the cert (e.g., <code>"/CN=your-user"</code>). | ||
| + | |||
| + | == Authentication options == | ||
| + | * Certificates | ||
| + | * [[Bearer tokens]] | ||
| + | * [[Authenticating proxy]] | ||
Revision as of 16:11, 25 August 2022
https://kubernetes.io/docs/reference/access-authn-authz/authentication/
Accounts
- Service accounts are users managed by the Kubernetes API. They are bound to specific namespaces, and created automatically by the API server or manually through API calls. Service accounts are tied to a set of credentials stored as Secrets, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API.
- Users: "normal" user accounts cannot be added via an API call, any user that presents a valid certificate signed by the cluster's certificate authority (CA) is considered authenticated.[1]. Kubernetes determines the username from the common name field in the
'subject'of the cert (e.g.,"/CN=your-user").
Authentication options
- Certificates
- Bearer tokens
- Authenticating proxy
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
- A user store like Keystone or Google Accounts
Related
kubectl create serviceaccountkubectl edit configmap aws-authgke-gcloud-auth-pluginkind: CertificateSigningRequest
See also
kubectl config[view | get-contexts | current-context | get-clusters | set-context | set-credentials ], ~/.kube/config, kubectl config --help,kubectx, Kubernetes contexts,KUBECONFIG, kubectl --kubeconfig- Kubernetes service account, ServiceAccount:,
kubectl get serviceaccounts, kubectl create serviceaccount, kubectl describe serviceaccount,kubernetes.io/service-account-token, Kubernetes users, Kubernetes groups, Kubernetes roles,ServiceAccountTokenNodeBinding - Kubernetes Authentication,
kubectl create serviceaccount, kubectl get serviceaccounts, CertificateSigningRequest, aws-auth, bearer tokens, EKS Authentication
Advertising:
