Symmetric and Asymmetric Keys - Fundamentals for Understanding Kubernetes Authentication

To understand Kubernetes authentication, let’s look at the basic cryptographic concepts of symmetric and asymmetric keys.

Basic Concepts of Encryption

Plaintext → [Encrypt] → Ciphertext
Ciphertext → [Decrypt] → Plaintext

• Plaintext: The original, unencrypted data
• Ciphertext: The encrypted data
• Key: A secret value used for encryption/decryption

Symmetric Key Encryption

Concept

    flowchart LR
    subgraph "Sender"
    P1["Plaintext"]
    end
    
    subgraph "Receiver"
    P2["Plaintext"]
    end

    subgraph "Encryption/Decryption Process"
    E["Encrypt"]
    D["Decrypt"]
    K(("Symmetric Key Secret"))
    end

    P1 --> E
    E -- "Ciphertext" --> D
    D --> P2
    K -.-> E
    K -.-> D
  

Key point: the same key is used for both encryption and decryption

Characteristics

Representative Algorithms

Example: AES-256

# Pseudocode example
key = "0123456789abcdef0123456789abcdef"  # 256 bits (32 bytes)
plaintext = "Hello, Kubernetes!"

# Encryption
ciphertext = AES_Encrypt(key, plaintext)
# Result: "a1b2c3d4e5f6..." (ciphertext)

# Decryption
decrypted = AES_Decrypt(key, ciphertext)
# Result: "Hello, Kubernetes!" (original restored)

The Problem with Symmetric Keys: Key Distribution

    sequenceDiagram
    participant A as Alice
    participant B as Bob
    Note over A,B: How do we deliver the key?
    A->>B: Send the symmetric key (Secret Key)?
    Note right of B: Problem: risk of interception!
    Note over A,B: n people communicating need n(n-1)/2 keys
  

The Essence of the Key Distribution Problem

“The Key Delivery Paradox”

Situation: Alice wants to send a secret message to Bob

Problems:

1. A shared key is needed to encrypt the message
2. But there is no safe way to deliver the key
3. If the key is intercepted by a hacker in transit, all communication is exposed!

Paradox: “Secure communication requires secure key delivery, but secure key delivery already requires secure communication.”

Key Distribution Scenarios

Key Management Complexity

Number of keys needed when n people communicate with each other: n(n-1)/2

The Problem Asymmetric Keys Solved: Key Distribution

The Core Idea of Asymmetric Keys

    sequenceDiagram
    participant A as Alice
    participant B as Bob
    Note over B: 1. Generate a key pair (public key/private key)
    B->>A: 2. Distribute the public key (accessible to anyone)
    Note over A: 3. Encrypt the message with Bob's public key
    A->>B: Send the ciphertext
    Note over B: 4. Decrypt with own private key (only I can)
  

Ways to Distribute Public Keys

1. Publish on a website: Post it so anyone can download it, e.g., https://bob.com/public-key.pem
2. Public key directory: Register it on a key server (e.g., keys.openpgp.org) so it can be searched
3. Digital certificate (CA): A certificate in which a trusted authority (CA) binds the owner’s information and public key together and signs it

Pros/Cons of Asymmetric Keys

Asymmetric Key Encryption

Concept

    flowchart TD
    subgraph "Sender"
    P1["Plaintext"] --> E["Encrypt"]
    end
    
    subgraph "Receiver"
    D["Decrypt"] --> P2["Plaintext"]
    end

    E -- "Ciphertext" --> D
    
    K1["Receiver's Public Key"] -.-> E
    K2["Receiver's Private Key"] -.-> D
  

Two Usage Modes

1. Confidentiality - Encryption

• Method: Encrypt with the receiver’s public key → decrypt with the receiver’s private key
• Result: Guarantees secure communication that only the receiver can read

2. Authentication - Digital Signature

• Method: Sign with the sender’s private key → verify with the sender’s public key
• Result: Confirms the sender’s identity and prevents data tampering (non-repudiation)

Hybrid Approach: TLS/SSL

Modern encrypted communication combines the strengths of symmetric and asymmetric keys.

TLS Handshake Flow (Simplified)

    sequenceDiagram
    participant C as Client
    participant S as Server
    
    C->>S: 1. ClientHello (send supported cipher suites)
    S->>C: 2. ServerHello + certificate (includes server public key)
    Note over C: 3. Verify certificate and generate pre-master secret
    C->>S: 4. Send pre-master secret encrypted with server public key
    Note over S: 5. Decrypt with private key to obtain the secret
    Note over C,S: 6. Both sides generate the same session key (symmetric key)
    C<->>S: 7. Begin high-speed encrypted communication with the generated symmetric key
  

💡 Note: The flow above is simplified and follows the classic RSA key exchange (TLS 1.2 and earlier). In TLS 1.3 the session key is derived through an ephemeral ECDHE exchange, and the server certificate’s key is used only to sign the handshake.

Relevance to Kubernetes

These mechanisms are used in various security areas inside Kubernetes.

1. API Server TLS: Uses server/client certificates (asymmetric keys) to authenticate and establish the connection, then symmetric keys to encrypt the actual traffic
2. ServiceAccount: Signs tokens with a private key and verifies they have not been tampered with using the public key
3. Secret encryption: Encrypts data with AES (symmetric key) before storing it in etcd; the encryption keys can be managed through an external KMS

Summary

Understanding how symmetric and asymmetric keys work together in a hybrid scheme is the starting point of Kubernetes security.