logo

Kubernetes - Auth

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 (CN) 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 group.
  • 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

  • User login to IdP (OIDC)

  • IdP provides access_token, id_token and refresh_token.

  • User call kubectl with --token using the id_token or add the id_token to kubeconfig.

  • kubectl call API Server with Authorization header in http requests.

    Authorization: Bearer xxxxxxxxxxxxxxxxx

  • API Server verifies the JWT token.

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:

Local Auth vs Cross Cluster

  • local authn: using kube-apiserver (using service account token)
    • native Kubernetes identity, a Config can be obtained through rest.InClusterConfig().
  • cross cluster authn: using an identity service (using STS token)
logo
PRIVACY POLICYABOUT中文