Service mTLS
0-day streakReview

Your progress

Level 1

0 XP100 XP to level 2
0day streak
0best streak
0topics started
0cards reviewed
    Review cards

    Progress is stored only in this browser. No account is required.

    Service-to-service auth and mTLS: the 60-second story

    Service-to-service auth

    One compromised pod can call your payments database.

    Many systems trust anything inside the VPC, with one edge firewall and plain HTTP within. One foothold, say a vulnerable library, reaches every service.

    What proves who is calling?

    Bad: Its IP address

    Pods churn and IPs get reused. Tomorrow it may be another workload.

    Good: A certificate per workload

    Verify every call as if it came from the internet.

    In mutual TLS, both sides prove they hold their key.

    Each signs a transcript of this very handshake, nonces included. A recorded handshake is useless to replay, and no secret crosses the wire.

    12 h

    the most a stolen certificate is worth

    Revocation is classic PKI’s weak spot, so workload certificates live hours. Renew at half-life, and a broken CA still has 6 hours before anything expires.

    Fetching a credential takes a secret. Who gives a new pod its first secret?

    The trick

    Nobody. It asks a local agent “who am I?”, presenting nothing. The agent identifies it via the kernel and kubelet.

    Let the mesh do mTLS, without breaking callers

    1. Server joins in PERMISSIVE: accepts mTLS and plaintext
    2. Clients join; their sidecars switch to mTLS
    3. Wait until metrics show zero plaintext
    4. Flip to STRICT, namespace by namespace

    mTLS everywhere. Done?

    Bad: Any valid certificate gets in

    A compromised reports pod still proves it’s reports: the flat network, encrypted.

    Good: Default deny, per method

    Each receiver admits named callers only: “checkout may POST /v1/charges”.

    Payments checks two proofs that must agree.

    mTLS proves orders is calling. A token exchanged for this hop, addressed to payments, says orders acts for user u_42.

    Remember

    Trust no network. Each workload proves who it is over mTLS with a short-lived certificate; default-deny policy decides what it may call; a per-hop token carries the user.