Kubernetes - Auth

Last Updated: 2024-01-31

Auth in Kubernetes

by cert
by token
by auth proxy

Subject: User vs ServiceAccount

API requests are

tied to a normal user
or tied to a service account
or are treated as anonymous requests.

Kubernetes does NOT have objects which represent normal user accounts.

Kubernetes DOES have a ServiceAccount:

bound to specific namespaces
created automatically by the API server or manually through API calls.
tied to a set of credentials stored as Secrets, which are mounted into pods allowing in-cluster processes to talk to the Kubernetes API.

RoleBinding

RoleBinding's subject can be SvcAcct, Group, or User. If user, the subject look like this

subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: system:authenticated

name: system:authenticated: for authenticated user.
name: system:anonymous: for anonymous user.
name: [email protected]

User

There's NO User objects in k8s.

Any user that presents a valid certificate signed by the cluster's certificate authority (CA) is considered authenticated.
Users can normally use a kubeconfig to talk to the api server. (kubelet, kube-scheduler are actually users, the certs can be found in configs in /etc/kubernetes).

Mapping from a Certificate to Subject:

CN (Common Name) => User.
O (Organization) => Group.

For example: /etc/kubernetes/kubelet.conf

Subject: O = system:nodes, CN = system:node:<node-name>

kubelet is a user named system:node:<node-name>, in system:nodes group.

Authn

by cert

Any user that presents a valid (x509) certificate signed by the cluster's certificate authority (CA) is considered authenticated. (cert can be set in kubeconfig by users[*].user.client-certificate-data / client-key-data)
Kubernetes determines the username from the common name field in the 'subject' of the cert (e.g., "/CN=bob")

by OIDC token

users[*].user.auth-provider.config

Authz

API authorization modes:

abac
rbac
node: only for kubelets with a credential that identifies them as being in the system:nodes group, with a username of system:node:<nodeName>.
webhook

API Server: the role based access control (RBAC) sub-system would determine whether the user is authorized to perform a specific operation on a resource.

Kubernetes uses a special-purpose authorization mode called Node Authorizer, that specifically authorizes API requests made by Kubelets. In order to be authorized by the Node Authorizer, Kubelets must use a credential that identifies them as being in the system:nodess group, with a username of system:node:<nodeName>.

client ca

server side: add --client-ca-file=SOMEFILE option to API Server. API Server will use this file to validate client certs. If a client certificate is presented and verified, the common name CN of the subject is used as the user name for the request, and O as the group names.

token

server side

static token file: use --token-auth-file=SOMEFILE option to specify a csv file specifying token, user, uid and groups
service account token: usually created automatically by the API server and associated with pods running in the cluster. Bearer tokens are mounted into pods at well-known locations
OIDC token: config server with oidc related flags --oidc-*. (the API server is not an OAuth2 client, rather it can only be configured to trust a single issuer. )
authn by webhook

client side

(OIDC) user login to IdP (Identity Provider), download id_token
user call kubectl with --token or add token to kubeconfig
kubectl call API Server with Authorization header in http requests

Authorization: Bearer xxxxxxxxxxxxxxxxx

IdP

According to CloudFlare: An identity provider (IdP) is a service that stores and verifies user identity. IdPs are typically cloud-hosted services, and they often work with single sign-on (SSO) providers to authenticate users.

IdP is only Authn, does not include Authz. E.g. active directory, okta.

RedHat Single Sign-On (the commercial version of Keycloak).

Standards / Protocols:

OIDC: OpenID Connect https://openid.net/connect/
SAML
LDAP