|
|
Line 58: |
Line 58: |
| =Controlling Access to the Kubernetes API= | | =Controlling Access to the Kubernetes API= |
| {{External|https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/}} | | {{External|https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/}} |
|
| |
| =Service Account=
| |
| {{External|https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/}}
| |
| {{External|https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/}}
| |
|
| |
| The service accounts are users managed by Kubernetes API, and they can be created via API calls, or automatically by the server. The service accounts are bound to specific namespaces. Among other things, a service account is tied to a set of credentials stored as Secrets, which are mounted into the pod allowing the in-cluster processes to talk to the Kubernetes API - see [[#Service_Accounts_and_Credentials|Service Accounts and Credentials]] below. Service accounts can be bound to specific roles - see [[#Service_Accounts_and_Roles|Service Accounts and Roles]] below.
| |
|
| |
| A service account token is a long-lived, static credential. If it is compromised, lost, or stolen, an attacker may be able to perform all the actions associated with that token until the service account is deleted, so use them sparingly.
| |
|
| |
| Processes in containers inside [[Kubernetes_Pod_and_Container_Concepts#Pods_and_Service_Accounts|pods]] can contact the API server, and they need an identity when doing so. A service account provides the identity for processes that run in a the pod. Processes will authenticate using the identity provided by the service account. By default, in absence of specific configuration, the pods will authenticate as the [[#Default_Service_Account|default service account]] in the namespace they are running in. A specific service account name can be specified in the [[Kubernetes_Pod_Manifest#serviceAccountName|pod manifest]] - also see [[#Non-Default_Service_Accounts|Non-Default Service Accounts]] below.
| |
|
| |
| The credentials (token) for a service account is placed into the filesystem of each container of the pod at <code>/var/run/secrets/kubernetes.io/serviceaccount/ca.crt</code> and by default is auto-mounted. In Kubernetes 1.6+ it can be opted out of auto-mounting by setting [https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server automountServiceAccountToken] in the service account manifest.<font color=darkgray>The default namespace to be used for namespaced API operations is placed on the filesystem of each container of the pod at <code>/var/run/secrets/kubernetes.io/serviceaccount/namespace</code></font>. Service accounts are rendered in logs using their [[#Service_Account_Full_Name|full name]] (e.g. "system:serviceaccount:blue:default).
| |
|
| |
| <code>kubectl</code> operations can be conducted under the identity of a specific service account using [[Kubectl#--as|kubectl --as option]]:
| |
| <syntaxhighlight lang='bash'>
| |
| kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...
| |
| </syntaxhighlight>
| |
| Also see: {{Internal|Kubernetes_Pod_and_Container_Concepts#Pods_and_Service_Accounts|Pod Service Account}}
| |
|
| |
| ==Service Account Full Name==
| |
|
| |
| Service accounts can be referred to using their full name <code>system:serviceaccount:<namespace>:<account-name></code> (e.g. <code>system:serviceaccount:blue:default</code>).
| |
|
| |
| ==Default Service Account==
| |
|
| |
| Each namespace comes with a default service account:
| |
|
| |
| <syntaxhighlight lang='yaml'>
| |
| apiVersion: v1
| |
| kind: ServiceAccount
| |
| metadata:
| |
| name: default
| |
| namespace: default
| |
| secrets:
| |
| - name: default-token-dddkl
| |
| </syntaxhighlight>
| |
|
| |
| A [[Kubernetes_Pod_Manifest#Example|pod]] whose service account was not explicitly configured will run with the default service account for its namespace, its configuration is equivalent with:
| |
| <syntaxhighlight lang='yaml'>
| |
| apiVersion: v1
| |
| kind: Pod
| |
| spec:
| |
| containers:
| |
| - name: [...]
| |
| [...]
| |
| serviceAccountName: default
| |
| [...]
| |
| </syntaxhighlight>
| |
| The a specific service account can be configured as such:
| |
| <syntaxhighlight lang='yaml'>
| |
| apiVersion: v1
| |
| kind: Pod
| |
| spec:
| |
| containers:
| |
| - name: [...]
| |
| [...]
| |
| serviceAccountName: something
| |
| [...]
| |
| </syntaxhighlight>
| |
|
| |
| ==Non-Default Service Accounts==
| |
|
| |
| To use a non-default service account, set <code>spec.serviceAccountName</code> field of the [[Kubernetes_Pod_Manifest#serviceAccountName|pod manifest]]. The service account has to exist at the time the pod is created, or it will be rejected. If the pod was already created, the service account cannot be updated.
| |
| ==Service Accounts and Credentials==
| |
| <font color=darkgray>Clarify the following:
| |
| * What are the default credentials associated with the default service account.
| |
| * How can this be association displayed.
| |
| * What happens with a newly created service account - does it need to be explicitly associated with those credentials or the association is done automatically upon creation.
| |
| </font>
| |
|
| |
| ==Service Accounts and Roles==
| |
| The recommended way to ensure that an application operates within a specific security scope is to bind a role or a set of roles to an application-specific service account. For more details, see: {{Internal|Kubernetes_Role_Based_Access_Control_Concepts|Role Based Access Control Concepts}}
| |
|
| |
| ==Service Account Operations==
| |
| * [[Kubernetes_Service_Account_Operations#Details_about_the_Namespace.27s_Default_Service_Account|Details about the Namespace's Default Service Account]]
| |
| * [[Kubernetes_Service_Account_Operations#Deploy_a_Service_Account.2C_a_Role_and_a_Role_Binding_with_a_Helm_Chart|Deploy a Service Account, a Role and a Role Binding with a Helm Chart]]
| |
| * [[Kubernetes_RBAC_Operations#Assigning_a_Cluster_Role_to_a_Service_Account|Assigning a Cluster Role to a Service Account]]
| |
|
| |
|
| =Role Based Access Control (RBAC)= | | =Role Based Access Control (RBAC)= |
Internal
API Server Authentication - Identity while Accessing the Cluster
The identity while accessing the Kubernetes cluster is associated with a (usually human) user that is authenticated while accessing the cluster or with a service account, which provides identity to pods and containers running inside the pods, which are making API requests. If an API request is not associated with any of these identities, it is treaded as an anonymous request.
Identities
User
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/
Users are sometimes referred to as "users accounts" or "normal users". There is no "User" Kubernetes API resource, and users cannot be added through an API call. It is assumed that a cluster-independent service manages users. That service can be implemented as a username/password file, a user store like Google Accounts, or an administrator that distributes private keys. When the authentication credentials are presented to the API server, the API server extracts the user name from the credentials (e.g. from the common name field in the "subject" of the certificate, "/CN=alice").
User Operations
Group
Anonymous Request
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests
When the API server handles a request, it first attempts to authenticate the identity making the request with one of the available authentication methods. If all authentication methods fail, and if anonymous request support is enabled, the identity is treated as anonymous requests, and given a username of system:anonymous
and a group of system:unauthenticated
.
API Authentication Strategies
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies
Kubernetes provides various authentication strategies to be used by the clients that send API requests into the Kubernetes API server. These authentication strategies are implemented by the server's authentication plugins.
Client X.509 Certificates
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#x509-client-certs
Bearer Tokens
kubectl allows specifying a bearer token in-line with --token
:
kubectl --token aHR0c...NiYg get pods
Webhook Token Authentication
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication
EKS Webhook Token Authentication
EKS has native support for webhook token authentication. See:
- EKS Webhook Token Authentication
Service Account Tokens
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens
Static Token File
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#static-token-file
Bootstrap Tokens
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#bootstrap-tokens
Authenticating Proxy
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authenticating-proxy
HTTP Basic Auth
OpenID Connect Tokens
- https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens
Controlling Access to the Kubernetes API
- https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
Role Based Access Control (RBAC)
- Kubernetes Role Based Access Control (RBAC) Concepts
Pod and Container Security
For more details on pod and container security concepts, including pod and container security contexts and pod security policies, see:
- Pod and Container Security
Cluster Administrator
Miscellaneous Subjects
Certificates Required by a Kubernetes Cluster
- https://kubernetes.io/docs/setup/best-practices/certificates/
Transport Security
- https://kubernetes.io/docs/reference/access-authn-authz/#transport-security