Kubernetes - Auth
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
- 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's subject can be
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]
- 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
- Kubernetes determines the username from the common name field in the 'subject' of the cert (e.g., "/CN=bob")
by OIDC token
API authorization modes:
- node: only for kubelets with a credential that identifies them as being in the
system:nodes group, with a username of
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
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.
- static token file: use
--token-auth-file=SOMEFILEoption to specify a csv file specifying
- 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
- (OIDC) user login to IdP (Identity Provider), download id_token
- user call kubectl with
--tokenor add token to kubeconfig
- kubectl call API Server with
Authorizationheader in http requests
Authorization: Bearer xxxxxxxxxxxxxxxxx
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/