01 - Cryptography and PKI Foundations

kubernetes/security kubernetes/networking

TLS

Core Idea

Kubernetes security rests on crypto fundamentals: asymmetric encryption hides data but cannot prove who sent it, so digital signatures and certificates close the identity gap.

• The authentication problem: if Bob publishes a public key, how does Alice know it is Bob’s and not an attacker’s (MitM)?
• The solution: digital signatures and certificates as the building blocks.
• Frames the rest of the PKI series around these mathematical and logical primitives.

To understand how Kubernetes secures its cluster components, we must first break down the security architecture into its fundamental mathematical and logical building blocks.

The Authentication Problem: Who Holds the Key?

Asymmetric encryption secures confidentiality, but it does not guarantee identity.
If Bob publishes a public key, how does Alice know that public key actually belongs to Bob, and not an attacker (Eve) performing a Man-in-the-Middle (MitM) attack?
If Eve intercepts Alice’s request and gives Alice Eve’s public key, Alice will encrypt the message for Eve, thinking she is sending it to Bob.

The Solution: Digital Signatures & Certificates

A. Digital Signatures

A digital signature is the reverse of encryption: the owner encrypts a hash of their data using their private key. Anyone can decrypt the signature using the owner’s public key to verify that:

1. The data has not been modified (integrity).
2. The data was signed by the holder of that specific private key (non-repudiation).

B. X.509 Digital Certificates

A digital certificate is a standardized wrapper (X.509 format) that binds a Public Key to an Identity (Subject). It contains:

• Subject: The name of the owner (e.g., Common Name CN=kube-apiserver).
• Subject Public Key: The public key being certified.
• Issuer: The name of the authority that verified the identity.
• Validity Dates: When the cert starts and expires.
• Digital Signature: The signature created by the Issuer’s private key.

C. Certificate Authority (CA)

A Certificate Authority is a globally or locally trusted third party.

1. You generate a Certificate Signing Request (CSR) containing your identity and public key.
2. The CA verifies your identity.
3. The CA signs the CSR with its CA Private Key, generating a Certificate.
4. Anyone who trusts the CA’s Public Certificate can verify the signature on your certificate and thus trust your identity.

       [ Client Device ] trusts CA's Root Certificate (ca.crt)
              │
              │ (1) Connects & presents server.crt
              ▼
       [ Server Component ]
              │
              └─► server.crt is signed by ca.key ──► Client verifies signature ──► Trust Established!