Kubernetes Security Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 85: Line 85:
==Service Account Full Name==
==Service Account Full Name==


Service accounts can be referred to using their full "system:serviceaccount:<namespace>:<account-name> (e.g. "system:serviceaccount:blue:default).
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==
==Default Service Account==

Revision as of 17:22, 3 May 2021

Internal

Transport Security

Identity while Accessing the Cluster

The identity while accessing the Kubernetes cluster is either associated with a (usually human) user that is authenticated while accessing the cluster, with a service account, which provides identity to pods. If an API request is not associated with any of these identities, it is treaded as an anonymous request.

Anonymous Request

https://kubernetes.io/docs/reference/access-authn-authz/authentication/#anonymous-requests

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/

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

Service Account

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
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. Service accounts can be bound to specific roles.

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 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 in the namespace they are running in. A specific service account name can be specified in the pod manifest - also see Non-Default Service Accounts below.

The credentials (token) for a service account is placed into the filesystem of each container of the pod at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt and by default is auto-mounted. In Kubernetes 1.6+ it can be opted out of auto-mounting by setting automountServiceAccountToken in the service account manifest.The default namespace to be used for namespaced API operations is placed on the filesystem of each container of the pod at /var/run/secrets/kubernetes.io/serviceaccount/namespace. Service accounts are rendered in logs using their full name (e.g. "system:serviceaccount:blue:default).

kubectl operations can be conducted under the identity of a specific service account using kubectl --as option:

kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...

Also see:

Pod Service Account

Service Account Full Name

Service accounts can be referred to using their full name system:serviceaccount:<namespace>:<account-name> (e.g. system:serviceaccount:blue:default).

Default Service Account

Each namespace comes with a default service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
secrets:
- name: default-token-dddkl

A pod whose service account was not explicitly configured will run with the default service account for its namespace, its configuration is equivalent with:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: [...]
    [...]
  serviceAccountName: default
[...]

The a specific service account can be configured as such:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: [...]
    [...]
  serviceAccountName: something
[...]

Non-Default Service Accounts

To use a non-default service account, set spec.serviceAccountName field of the 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 Account Operations

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/