Kubernetes TLS Check List

KodeKloud

- 3 minutes read - 425 words

Kubernetes cluster security relies heavily on X.509 certificates for authenticating nodes, users, and services to the API server. Properly configured certificates ensure that each component presents the correct Common Name (CN), Organization (O) fields, and Extended Key Usage (EKU) values. The topics below cover certificate requirements for nodes and users, the ALT names needed on the API server, and how to manage certificates using cert-manager or manual OpenSSL workflows.

Node Certificates

Nodes that authenticate themselves to the API server use a certificate that includes SYSTEM:NODE:<NodeName> in the subject, and the nodes themselves must be in a group called SYSTEM:NODES.

User Certificates

User certificates used to authenticate users to the API server make use of the Organization element in the CN to include SYSTEM:MASTER (for super users) or SYSTEM:<Group>, and the user must be present in an appropriate group.

openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"

Deployment Methods

  • kubeadm configures inter-cluster certificates for you.
  • If you handle this manually, you will need to generate each certificate and review the .service unit file for each service:
    • /etc/kubernetes/manifest/<service> (kubeadm)
    • /etc/systemd/system/<service> (Manual Deployment)

API Server ALT Names

Make sure that the API server includes all of its appropriate default ALT names, including the IPs. This is in addition to the primary CN of kube-apiserver:

  • kubernetes.default.svc.cluster.local (if --service-dns-domain is cluster.local)
  • kubernetes.default.svc
  • kubernetes.default
  • Kubernetes

Extended Key Usage

extendedKeyUsage = serverAuth, clientAuth
Note

There is a built-in cert-manager to help facilitate certificate management.

cert-manager

Generate an Issuer Resource

Once cert-manager is deployed, generate an issuer resource:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-ca-issuer
spec:
  ca:
    secretName: ca-secret # Secret containing your CA cert and key

Generate a Certificate Resource

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-kubernetes-service-cert
spec:
  secretName: my-kubernetes-service-tls
  issuerRef:
    name: my-ca-issuer
    kind: Issuer
  commonName: my-kubernetes-service
  dnsNames:
    - my-kubernetes-service.example.com
  ipAddresses:
    - 192.168.1.100
  subject:
    organizations:
      - MyOrganization

Submit a Signing Request (Client)

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: myuser # example
spec:
  # This is an encoded CSR. Change this to the base64-encoded contents of myuser.csr
  request: … <base64 encoded cert> # make sure to use base64 -w 0
  signerName: kubernetes.io/kube-apiserver-client
  expirationSeconds: 86400  # one day
  usages:
    - client auth
Note

base64 -w 0 disables wrapping.

Important

For user client certificates, it is important to set the CN and O attributes of the CSR. CN is the name of the user and O is the group that this user will belong to. You can refer to RBAC for standard groups.

openssl req -new -key myuser.key -out myuser.csr -subj "/CN=myuser"

Checklist

📎 Download kubernetes-certs-checker.xlsx

References