logo

Kubernetes - Auth

Auth in Kubernetes

  • by cert
  • by token
  • by auth proxy

Subject: User vs ServiceAccount

Subject can be User, Group, or ServiceAccount.

- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: [email protected]

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 derives:
    • the username from the common name field (CN) in the 'subject' of the cert (e.g., /CN=bob).
    • the group membership from the organization field (O).

by OIDC token

User provides OpenID Connect formatted ID token to API server in each HTTP request. ID token takes the form of JSON Web Token (JWT) and contains information about the user including group membership. API Server validates ID token and then derives user name/group information from ID token.

In kubeconfig: users[].user.auth-provider.config

by Authentication Proxy

In this configuration, the intermediary server takes requests, authenticates the user and then attaches additional HTTP headers containing user information. This request is then sent to the API Server on behalf of the users and its response passed back. API Server validates intermediary server identity before checking HTTP request headers for user and group membership.

by Webhook Token Authentication

User sends requests to API Server including bearer token. API server sends token review request containing token to remote service. Remote service is expected to validate the token and fill in the response body containing user information.

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中文