# Security Hardening and Compliance Assessment of Kubernetes Control Plane and Workloads
## 4 Security Hardening of Kubernetes Components
### Identity and Access Management
#### 4.4.2 Using Tokens  
Tokens in Kubernetes function as a versatile and secure mechanism for authenticating users and services that engage with the Kubernetes API server. By comprehending the various categories of tokens, including bootstrap tokens, static tokens, and OIDC tokens, system administrators can devise authentication strategies customized for specific environments.  
1. Static tokens are a straightforward mechanism for user authentication to the Kubernetes API server. These tokens are pre-established and maintained in a static file on the control plane. They offer a straightforward method for configuring basic authentication in small-scale or testing environments; however, they are not advisable for production due to security issues. Static tokens are transmitted as a CSV file containing user IDs, names, tokens, and optional group names. The API server retrieves bearer tokens from a file when the -token-auth-file=FILENAME option is specified in the command line. A static token file can be generated in /etc/kubernetes/static-token.csv on the controller node and must contain a minimum of three columns: token, username, and user-id. The Controller API manifest is at  
Figure 7: Using client certificates for authorization.  
/etc/kubernetes/manifests/kube-apiserver.yaml must be updated to include the -token-auth-file flag.
2. Bootstrap tokens are basic bearer tokens designed to create new clusters or integrate new nodes into an existing cluster. They are ephemeral tokens engineered explicitly for the bootstrapping process to authenticate a node to the cluster's control plane node. Consequently, they are designed to facilitate the kubeadm process but may also be utilized in alternative contexts. Bootstrap tokens are retained as secrets within the kube-system namespace. The Bootstrap Token authenticator can be activated using the subsequent flag on the API server: -activate-bootstrap-token-authentication. Figure 8 illustrates the default bootstrap token created by the kubeadm init process and stored as a secret in the kube-system namespace:
3. The OpenID Connect protocol is developed by extending the existing OAuth2 protocol. Kubernetes lacks an OpenID Connect identity provider. Identity providers such as Google or Azure may be utilized. External identity providers can be seamlessly integrated with Kubernetes authentication workflows as needed. OpenID Connect is a derivative of OAuth2 endorsed by numerous OAuth2 providers. The principal improvement it provides over OAuth2 is incorporating an ID Token in the response in addition to the access token, with the ID Token being a JSON Web Token (JWT). To implement OpenID Connect with Kubernetes, one must first authenticate with an identity provider, such as Microsoft Entra ID, Salesforce, or Google. Upon logging in, the identity provider will issue an access_token, an id_token, and a refresh_token. When utilizing kubect to engage with the Kubernetes cluster, the id_token must be provided either via the -token flag or by incorporating it directly into the kubeconfig file. Upon configuration, kubect will transmit the id_token in the authorization header during API server requests. The API server will authenticate the JWT signature to confirm the token's validity. It will also check whether the token has expired to verify its validity. The API server will respond to kubectl if the user possesses authorization.  
Using tokens in Kubernetes improves security by facilitating precise access control and authentication. Tokens, including service account tokens and ephemeral tokens from OIDC providers, ensure that only authorized users or services can access the Kubernetes API. They can be precisely defined to restrict access to resources or namespaces and are more readily rotated and revoked than static credentials. That mitigates the risk of credential exposure and enhances auditability and compliance in secure settings.  
Figure 8: Using bootstrap tokens.