X.509 certificate authentication in Kubernetes¶

X.509 certificate authentication is a method used in Kubernetes to verify the identity of users accessing the cluster^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. It operates as part of the authentication layer, distinct from but complementary to the authorization layer (such as [[RBAC]]).^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]

Authentication vs. Authorization¶

In Kubernetes, any request to access resources must pass through two stages: Authentication (Who are you?) and Authorization (What can you do?)^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. X.509 certificates are used strictly for the authentication phase to establish trust between a client and the API Server^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

User Types¶

Kubernetes distinguishes between two main categories of identities^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]:

Normal Users: typically interact via kubectl or RESTful APIs.
Service Accounts: namespaced resources intended for in-cluster processes (Pods).

Mechanism¶

The Role of the CA¶

The Kubernetes API Server acts as a Certificate Authority (CA)^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. For a client certificate to be valid, it must be signed by the cluster's CA certificate^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. This is similar to the trust model used in HTTPS, where the CA provider is the Kubernetes cluster itself^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Identity Mapping¶

When a client presents an X.509 certificate, the API Server extracts the user's identity from the certificate's subject field^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]. Specifically, the Common Name (CN) is used as the username, and the Organization (O) field is used as the group^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Implementation Process¶

To implement X.509 authentication for a user, a standard workflow involving the generation of keys and a Certificate Signing Request (CSR) is used^{[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]}[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

Generate Private Key: Create a private key for the user^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
```
[OpenSSL](<./openssl.md>) genrsa -out pod-viewer.key 2048
```
Create CSR: Generate a Certificate Signing Request specifying the CN (User) and O (Group)^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
```
[OpenSSL](<./openssl.md>) req -new -key pod-viewer.key -out pod-viewer.csr -subj "/CN=pod-viewer/O=app"
```
Sign with CA: Use the cluster's CA certificate and key to sign the CSR, generating the final client certificate^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].
```
[OpenSSL](<./openssl.md>) x509 -req -in pod-viewer.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out pod-viewer.crt -days 365
```

Configuration¶

Once the certificate (pod-viewer.crt) and key (pod-viewer.key) are generated, they must be added to the Kubernetes configuration file (kubeconfig)^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md].

The kubectl config set-credentials command is used to assign the certificate to a user context^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]:

[kubectl](<./kubectl.md>) config set-credentials pod-viewer \
    --client-certificate=pod-viewer.crt \
    --client-key=pod-viewer.key \
    --embed-certs=true

[[RBAC]]
[[Service Account]]
[[Kubeconfig]]

Sources¶

^[400-devops-06-kubernetes-k8s-ithelp-day29-readme.md]