logo

Kubernetes - Auth

Last Updated: 2023-08-26

Auth in Kubernetes

  • by cert
  • by token
  • by auth proxy

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]

Authn

by cert

  • Any user that presents a valid certificate signed by the cluster's certificate authority (CA) is considered authenticated. (cert can be set in kubeconfig by users[*].user.client-certificate-data or 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:

logo
PRIVACY POLICYABOUT中文