Skip to main content

Security in Microservices - Slides

SLIDE DECK: MODULE 07 (NEW) - SECURITY IN MICROSERVICES - V2.0 (FRESHER-OPTIMIZED)​

Total Duration: 120 minutes (Concept/Lecture/Demo) Audience: Fresher/Employee (Completed Modules 01-06)

Slide 1: Title Page

  • Content:
    • (Company / Training Unit Logo)
    • MODULE 07: SECURITY IN MICROSERVICES
    • Perimeter Security, Service Trust & Secrets Management
    • Tools: Kong (AuthN/AuthZ), mTLS, Secrets Management
    • Trainer: (Your Name)
    • Date: (Training Date)
  • Visualization: *

[Image of a castle with multiple layers of defense]

* Key visual: A "castle" (the system) protected by multiple layers:
    1.  **Main Gate:** `[Kong Gateway (AuthN/AuthZ)]`
    2.  **Guards (Service Trust):** `[Service A] <--(mTLS/JWT)--> [Service B]`
    3.  **Treasury (Secrets):** `[Docker/K8s Secrets]` (holding DB passwords)
  • Instructor Script:
    • "Welcome to Module 07. This is the 'final piece' and the most important one. We have built a 'castle' (system) that is 'Safe' (SAGA), 'Fast' (Cache), and 'Visible' (O11y)."
    • "But we haven't 'locked the gate.' Anyone can walk right into our API. Our services are 'talking' to each other without 'verifying' identities. DB passwords are 'left out' in .env files."
    • "Today, we learn how to 'Secure' our microservice system. We'll learn to 'lock the gate' (Kong Auth), 'verify the guards' (S2S Trust), and 'secure the treasury' (Secrets Management)."

Slide 2: Session Agenda (Updated V2.0)

  • Content:
    • AGENDA (120 MINUTES)
    • P1. The Problem: AuthN/AuthZ in Monoliths (FastAPI) vs. Microservices
    • P2. Layer #1: Perimeter Security (Gateway)
      • (Demo) Kong OSS: JWT Plugin (AuthN) + ACL Plugin (AuthZ)
    • P3. Layer #2: Service-to-Service (S2S) Trust
      • Concepts: mTLS (via Service Mesh) vs. Internal JWT (S2S Accounts)
      • "Zero Trust" & Safe Token Propagation.
    • P4. Layer #3: Secrets Management
      • Why .env is "bad".
      • Solution: Docker Secrets & K8s Secrets (Base64 != Encrypt)
      • Concept: Rotation.
    • P5. Layer #4: Secure Observability & Hardening [Upgraded]
      • (Connect M05) Secure Logging: Mask PII, don't log tokens.
      • (Connect M03/06) Hardening: RabbitMQ/Redis TLS & ACLs.
    • P6. Summary: The New Security Rubric for the Final Project.
  • Visualization:
    • A 6-step timeline, designed like the 4 "layers" of an onion. P2 (Gateway) and P3 (S2S) are the focus.
  • Instructor Script:
    • "Our agenda will move 'from the outside in'."
    • "P1: We'll see why Depends(get_current_user) (from FastAPI) is 'not enough' for microservices."
    • "P2: We 'lock the main gate' (Kong OSS) with JWT (authentication) and ACL (authorization). P3: We 'teach' services to 'trust' each other (Internal JWT). P4: We 'lock' our DB passwords in Docker Secrets."
    • "P5: We ensure our 'security cameras' (O11y) don't 'record' (log) 'passwords' (PII). Finally, the new Rubric for the Final Project."

Slide 3: Learning Objectives (Updated V2.0)

  • Content:
    • OBJECTIVES (AFTER THIS MODULE, YOU WILL BE ABLE TO...)
    • 1. Explain: The distributed security risks (Gateway, S2S, Secrets, Logging).
    • 2. Implement: Configure Kong OSS using the JWT Plugin (AuthN) and ACL Plugin (AuthZ by group). [Upgraded]
    • 3. Distinguish: S2S trust strategies (like mTLS vs. Internal JWT with JWKS/short TTL). [Upgraded]
    • 4. Design: A "Secure Logging" process (mask PII, don't log tokens, do log trace_id & subject).
    • 5. Identify: How to use Docker/K8s Secrets and understand why Base64 != Encryption. [Upgraded]
  • Visualization:
    • 5 icons: [Icon: Brain (Explain)], [Icon: Kong Logo + ACL (Implement)], [Icon: Fork/Split (Distinguish)], [Icon: Secure Log (Design)], [Icon: Docker/K8s Logo (Identify)].
  • Instructor Script:
    • "This is our commitment. After this module, you must be able to 'Explain' why microservice security is 'hard' (Objective 1)."
    • "Most importantly, Objective 2: You must be able to 'configure' Kong OSS using JWT (for auth) and ACL (for group authorization). We will focus on the free version."
    • "You must 'Distinguish' mTLS from Internal JWT (Objective 3), 'Design' a 'clean' log (Objective 4) and 'know' how to use Docker Secrets (Objective 5)."

Slide 4: P1 - Problem: AuthN/AuthZ in Monoliths vs. Microservices

  • Content:
    • P1: WHY ISN'T THE OLD AUTHN/AUTHZ "ENOUGH"?
    • Monolith Scenario (FastAPI):
      • Client sends JWT Token.
      • API (FastAPI) receives Token.
      • Middleware/Dependency (Depends(get_current_user)) itself verifies the Token signature -> Gets user_id.
      • Simple, works great.
    • Microservice Scenario (The Black Box):
      • Client -> [Kong] -> [Order Svc] -> [Payment Svc]
    • THE 5 "DEADLY" QUESTIONS:
      1. Who should 'verify' the JWT? Kong? Or all 10 services (repeating code)?
      2. Trust: Order Svc calls Payment Svc. How does Payment Svc know (trust) it's the Order Svc (a colleague) and not a Hacker?
      3. Propagate: Order Svc knows user_id="123". How does Payment Svc (in step 2) know this transaction is for user_id="123"? (Token Propagation).
      4. Secrets: Where are the passwords for the 10 databases 'stored'?
      5. Logging: Does the log trace_id="abc" also 'log' the full JWT Token? (Leakage).
  • Visualization: *
    • Diagram 1 (Monolith): [Client] -> [FastAPI (Verify JWT)] -> [DB]. (Simple).
    • Diagram 2 (Microservice): [Client] -> [Kong] -> [Order] -> [Payment].
    • 5 [Icon: Question Mark] are placed on 5 "blind spots" (locations) on Diagram 2, corresponding to the 5 questions.
  • Instructor Script:
    • "In the FastAPI course, you learned Depends(get_current_user). It's excellent... for a Monolith."
    • "But in a Microservice, [Point to Diagram 2] it creates 5 'deadly questions'."
    • "1. Who 'checks' the token? Kong, or all 10 services?"
    • "2. [EMPHASIZE] Order Service calls Payment. Does Payment 'trust' Order? Or is it 'open' to the world?"
    • "3. Order knows the user_id. How does Payment know? (Token Propagation)."
    • "4. Where are the DB passwords? 5. Did you 'accidentally' log the JWT Token to Kibana?"
    • "This module will answer all 5 questions."

Slide 5: Section Introduction - Layer #1: Perimeter Security

  • Content:
    • 01. LAYER #1: PERIMETER SECURITY (GATEWAY)
    • Locking the Main Gate
  • Visualization:
    • Section introduction slide with title and subtitle against background.
    • Visual emphasis on "Gateway" and "Kong" as the entry point.
  • Instructor Script:
    • "We're now entering the first layer of our security castle: the Gateway."
    • "This is where we 'lock the main gate' and control who gets in."
    • "We'll use Kong OSS to implement Authentication and Authorization at the perimeter."

Slide 6: P2 - Layer #1: Perimeter Security (Kong OSS) (UPGRADED)

  • Content:
    • LAYER #1: PERIMETER SECURITY (GATEWAY)
    • Philosophy: "Don't trust Clients. Authenticate (AuthN) and Authorize (AuthZ) AT THE GATE."
    • Tools (Kong OSS):
      • 1. AuthN (Authentication): JWT Plugin
        • Job: 'Verify' the JWT signature.
        • Flow: Client (User Alice) -> Send JWT -> Kong (Verify OK) -> X-Consumer-Username: Alice (Header) -> Order Svc.
      • 2. AuthZ (Authorization): ACL Plugin (Access Control List)
        • Job: Authorize based on 'Groups'.
        • Flow (Setup):
          1. Create Consumer Alice.
          2. Create a "Group" for Alice: POST /consumers/Alice/acls (Body: group=billing-admin)
          3. "Lock" a Route (e.g., POST /refund): Require 'Group' billing-admin.
        • Flow (Runtime):
          • Alice (in billing-admin) calls POST /refund -> OK (200).
          • Bob (in user) calls POST /refund -> FAILED (403 Forbidden).
    • Note (Advanced):
      • Fine-grained authorization (by scope) often requires Kong Enterprise (OIDC Plugin) or Custom Plugins.
  • Visualization: *
    • A 3-step diagram (OSS Version):
      1. [Client (No JWT)] -> [Kong (JWT Plugin)] -> [STOP (401 Unauthorized)]
      2. [User Bob (Group='user')] -> [Kong (ACL Plugin 'billing-admin')] -> [STOP (403 Forbidden)]
      3. [User Alice (Group='billing-admin')] -> [Kong (ACL Plugin 'billing-admin')] -> [PASS] -> [Refund Service]
  • Instructor Script:
    • "Answering question 1: 'Who verifies?' The answer: Kong."
    • "With Kong OSS (free), we use 2 plugins."
    • "One: JWT Plugin for 'Authentication' (AuthN). [Point to step 1] No JWT, Kong 'blocks' with 401."
    • "Two: ACL Plugin for 'Authorization' (AuthZ). [Point to steps 2, 3] We create 'Groups' (e.g., billing-admin). We 'lock' the /refund API to only this group. User Bob (in group user) calls -> 403. User Alice (in group billing-admin) calls -> 200."
    • "This method is simple and effective for Freshers. Fine-grained 'scope' (OIDC) authorization usually requires the Enterprise version or custom plugins."

Slide 7: P2 (Continued) - Token Propagation (UPGRADED)

  • Content:
    • THE PROBLEM: PROPAGATING USER CONTEXT
    • Bad Solution (Anti-Pattern): Propagate the entire User JWT everywhere.
      • Risk: Inventory Service 'accidentally' logs the JWT -> Hacker 'steals' the token.
    • Good Solution (Fresher-Friendly):
      1. Kong (Gateway): 'Verifies' JWT (JWT Plugin) -> 'Injects' X-Consumer-Username: "alice" Header. (Kong OSS can do this)
      2. Order Service (Edge Service): Receives X-Consumer-Username: "alice".
      3. Order Service (Async): When sending a RabbitMQ Message:
        • Do not propagate the JWT.
        • Pass the user_id (or username) in the Message Body (or a safe header).
        • body = {"order_id": 1, "total": 100, "user_id": "alice"}
      4. Payment Service (Internal): Receives the Message, trusts the user_id in the message (because it came from Order Service - which was S2S trusted).
  • Visualization: *
    • Diagram 1 (Bad): [JWT (Alice)] -> [Kong] -> [Order (JWT)] -> [Payment (JWT)] -> [Inventory (JWT)] (Token is everywhere - X mark).
    • Diagram 2 (Good): [JWT (Alice)] -> [Kong (Verify)] (JWT is 'stripped'). [Kong] -> (Header: X-Consumer-Username: "alice") -> [Order] -> (Message: {..., user_id: "alice"}) -> [Payment].
  • Instructor Script:
    • "This is question 3. How does Payment Service (at the end of the SAGA) know who placed the order?"
    • "Bad Way: [Point to Diagram 1] 'Throw' the original User JWT (Alice's) all over the system. This is a 'security nightmare'."
    • "Good Way (for Kong OSS): [Point to Diagram 2] Kong (the gate) 'verifies' the JWT, then 'throws it away.' But, it 'injects' a safe header X-Consumer-Username: "alice" (this is a feature of the JWT Plugin)."
    • "Order Service (the 'edge' service) 'reads' this header. When it 'sends' the async RabbitMQ message, it 'copies' that user_id into the message 'body.' Now Payment knows the user_id without ever seeing the original JWT."

Slide 8: Section Introduction - Layer #2: Service-to-Service Trust

  • Content:
    • 02. LAYER #2: SERVICE-TO-SERVICE TRUST
    • Zero Trust Between Internal Services
  • Visualization:
    • Section introduction slide with title and subtitle.
    • Visual emphasis on "S2S Trust" and "Zero Trust" concepts.
  • Instructor Script:
    • "Moving deeper into our castle, we reach the second layer: Service-to-Service Trust."
    • "Here, we ensure that services verify each other's identity before communicating."
    • "We'll explore mTLS and Internal JWT strategies for building trust."

Slide 9: P3 - Layer #2: Service-to-Service (S2S) Trust (UPGRADED)

  • Content:
    • LAYER #2: SERVICE-TO-SERVICE TRUST (ZERO TRUST)
    • Problem: Payment Service cannot tell the difference between Order Service and a Hacker.
    • "Zero Trust" Philosophy: "Trust no one, not even colleagues. Always verify."
    • Solution 1: mTLS (Mutual TLS) - "Show me your ID card"
      • How: Both services (Client A and Server B) must present a valid Certificate to each other.
      • When: Extremely secure. Often automated by a Service Mesh (Istio/Linkerd).
    • Solution 2: Internal JWT (Service Accounts) - "Tell me the password"
      • How: Order Service (using its Service Account) 'creates' a JWT (5 min TTL) -> Signs it.
      • Payment Service 'receives' the JWT -> 'Verifies' the signature (using Order Svc's Public Key).
      • Best Practice:
        • Use JWKS (JSON Web Key Set): Payment auto-fetches the Public Key from a /.well-known/jwks.json endpoint.
        • Short TTL (<= 5 min) + Key Rotation
  • Visualization: *
    • Diagram 1 (mTLS): [Order Svc] <-> [Service Mesh Proxy (Istio)] <--(Encrypted)--> [Service Mesh Proxy (Istio)] <-> [Payment Svc]. (Visualizes the 'automation').
    • Diagram 2 (JWT): [Order Svc (Sign JWT, TTL=5m)] -> [Payment Svc (Verify via JWKS)].
  • Instructor Script:
    • "Okay, we've 'locked the gate' (Kong) for users. Now for 'internal' traffic."
    • "[Point to Problem] The problem is: A Hacker 'gets inside' your network, pretends to be Order Service, and 'calls' Payment Service directly. Payment Service will 'obey' (because it 'trusts' all internal calls)."
    • "The 'Zero Trust' philosophy says: 'No.' Payment Service must ask: 'Are you really the Order Service?'"
    • "Way 1: mTLS (Mutual TLS). [Point to Diagram 1] Both sides 'show their ID cards' (Certificates) to 'check' each other. Very secure, very fast, but 'very hard' to set up manually. Usually, you let a 'Service Mesh' like Istio do it 'automatically'."
    • "Way 2 (More practical for labs): Internal JWT. [Point to Diagram 2] Order 'signs' a 'secret password' (a 5-min JWT), Payment 'checks' the password (via JWKS). In the Final Project, you'll choose one of these."

Slide 10: P3 (Continued) - Additional S2S Considerations

  • Content:
    • 03. LAYER #3: SECRETS MANAGEMENT
    • Protecting the Treasury
  • Visualization:
    • Section introduction slide with title and subtitle.
    • Visual emphasis on "Secrets" and "Vault" concepts.
  • Instructor Script:
    • "The third layer protects our most valuable assets: the secrets."
    • "This is where we secure database passwords, API keys, and other sensitive data."
    • "We'll learn why .env files are dangerous and how to properly manage secrets."

Slide 12: P4 - Layer #3: Secrets Management (UPGRADED)

  • Content:
    • LAYER #3: SECRETS MANAGEMENT
    • Problem: .env and Hard-coding (Risk)
      • db_pass = "my-secret-password-123" (Hard-code) -> Disaster.
      • DB_PASSWORD=... (In .env / docker-compose.yml) -> Better, but:
        • 'Checked-in' to Git (Disaster).
        • Hard to 'Rotate'.
    • Solution (Fresher): Docker Secrets
      • How (Docker Compose):
        1. Create file db_password.txt.
        2. docker-compose.yml declares the 'secret': 
          secrets:
            db_pass_secret:
              file: ./db_password.txt
          services:
            order-service:
              secrets: [db_pass_secret]
        3. App (Python) reads the password from a file: /run/secrets/db_pass_secret.
    • Solution (Production): K8s Secrets / Vault
      • K8s Secrets: Mounts the secret into the container.
      • Warning: K8s Secrets (by default) are just Base64 (to 'hide'), not Encryption. You need Sealed Secrets or Vault Injector for true security.
  • Visualization: *
    • Diagram 1 (Bad): [Git Repo (.env)] -> [Developer (Sees Pass)]. (X mark).
    • Diagram 2 (Good - Docker): [db_password.txt (Local)] -> [Docker Engine] -> (Mount as File) -> [App (/run/secrets/db_pass)]. (The .env file has no password).
  • Instructor Script:
    • "Question 4: Where is the DB password?"
    • "If you are 'hard-coding' or 'checking in' .env files to Git, that is a 'disaster'."
    • "The 'minimum' solution for our Lab is Docker Secrets. [Point to Diagram 2] You 'declare' the secret in docker-compose.yml. Docker 'mounts' that password into a file at /run/secrets/... inside the container. Your code 'reads' from that file. This way, the password is not in the docker-compose.yml (which can be checked into Git)."
    • "[EMPHASIZE] In production (K8s), you'll use 'K8s Secrets.' But remember: K8s Secrets are just 'hidden' (Base64), they are not 'encrypted'. For 'super security,' you need Vault."

Slide 14: Section Introduction - Layer #4: Secure Observability & Hardening

  • Content:
    • 04. LAYER #4: SECURE OBSERVABILITY & HARDENING
    • Protecting the Security Cameras
  • Visualization:
    • Section introduction slide with title and subtitle.
    • Visual emphasis on "O11y Security" and "Hardening" concepts.
  • Instructor Script:
    • "The final layer ensures that our monitoring tools don't become security vulnerabilities."
    • "We'll learn how to log safely without exposing sensitive data."
    • "And we'll harden our infrastructure tools like Redis and RabbitMQ."

Slide 15: P5 - Layer #4: Secure Observability & Hardening (UPGRADED)

  • Content:
    • LAYER #4: SECURE OBSERVABILITY & HARDENING
    • Risk 1: Leaking PII/Tokens via Logs
      • ERROR: Failed. UserToken: "eyJhbG..." Password: "123" ('Dirty' log).
      • Solution (M05): Structured Logging (JSON) + Masking (Logstash)
      • Must log trace_id + subject (userid), _NEVER log token.
    • Risk 2: Leaking PII via Message Queue (DLQ)
      • Failed message (with PII) -> 'pushed' to Dead-Letter-Queue (DLQ).
      • Admin 'views' DLQ in RabbitMQ UI -> Sees all customer PII.
      • Solution: Do not log the full body of a DLQ message. Must 'redact' PII before logging the error.
    • Risk 3: Tool Hardening
      • Redis:
        • Problem: Default is 'open' (no password).
        • Fix: Enable requirepass (ACL) and TLS.
      • RabbitMQ:
        • Problem: Using user/pass guest/guest (only for localhost).
        • Fix: Create separate user/vhost/permissions for each Producer/Consumer (Principle of 'Least Privilege').
  • Visualization: *
    • 3 risk diagrams:
      1. [Log (Token)] -> [Kibana (Leaked)] (X mark).
      2. [Message (PII)] -> [DLQ (Leaked)] (X mark).
      3. [Redis (Default)] / [RabbitMQ (guest/guest)] (X mark).
    • (Next to them are solutions: Masking, ACL, TLS).
  • Instructor Script:
    • "Finally, question 5: Are your 'security cameras' (O11y) 'spying' on you?"
    • "Risk 1: [Point to Diagram 1] You 'accidentally' log a JWT Token or Password to Kibana. Disaster. Solution: Use JSON log + Masking (from Module 05)."
    • "Risk 2: [Point to Diagram 2] A failed message (with PII) 'lands' in the DLQ. An admin 'views' the DLQ and 'sees' all the PII. Solution: 'Redact' PII before you log the DLQ error."
    • "Risk 3: [Point to Diagram 3] Your 'tools' (Redis, RabbitMQ) are 'wide open' (no password, or using guest/guest). You must enable ACL (passwords) and create separate users for each service."

Slide 16: P6 - Summary: New Security Rubric (For Final Project)

  • Content:
    • P6: NEW RUBRIC FOR FINAL PROJECT (SECTION E)
    • (Module 07/old -> 09/new) Will now include E. Security (15%)
    • Checklist (Mandatory):
    • 1. Gateway Policies:
      • [ ] (M02) Kong 'protects' at least 1 service with JWT Plugin.
      • [ ] (M02) (Bonus) Authorization with ACL Plugin (OSS) (by 'group').
    • 2. Service-to-Service Trust:
      • [ ] (M08) At least 1 pair of services (e.g., Order -> Payment) must authenticate each other (mTLS or Internal JWT).
    • 3. Secure Observability:
      • [ ] (M05) Log JSON + trace_id + subject (user_id).
      • [ ] (M05) Prove NO Tokens or PII (Credit Card, Password) are logged.
    • 4. Secrets Management:
      • [ ] (M08) NO hard-coded passwords/secrets in code/.env/docker-compose.yml.
      • [ ] (M08) Use Docker Secrets (or K8s Secrets) to 'inject' secrets at runtime.
    • 5. Hardening:
      • [ ] (M06) Redis has a 'password' (ACL) (not default).
      • [ ] (M03) RabbitMQ has a 'user/password' (not guest/guest).
  • Visualization: *
    • A 5-item checklist (Gateway, S2S, O11y, Secrets, Hardening) with [Icon: Checkbox] for each.
  • Instructor Script:
    • "To 'graduate,' your Final Project (now Module 09) will have a new 'Section E: Security' (15%)."
    • "This is the checklist. [Point to Checklist] I will be 'checking' 5 things:"
    • "1. Is Kong 'locking' with JWT and ACL (OSS)?"
    • "2. Do your services 'authenticate' each other (mTLS/Internal JWT)?"
    • "3. Are your logs 'clean' (have trace_id, no token)?"
    • "4. Where is your DB password 'stored' (Docker Secrets)?"
    • "5. Did you 'change' the default password for Redis/RabbitMQ?"
    • "This is the 'minimum' requirement to pass Security."

Slide 17: Q&A

  • Content:
    • Q & A
    • Questions about Security
  • Visualization:
    • A clean, minimal slide. Just the large letters "Q&A".
  • Instructor Script:
    • "Thank you. This is a 'dry' but 'vital' topic. Please, any questions about Security."

Slide 18: Thank You & Next Module

  • Content:
    • THANK YOU!
    • (Your Contact Info: Email, LinkedIn, etc.)
    • COMING UP NEXT...
    • Module 09: E2E Debugging & Final Project
    • We will "hunt" bugs and "submit" the Final Project (with the new Security Rubric)!
  • Visualization:
    • "Teaser" for Module 09 (the old Module 07).
    • An image of the 'SRE Detective' (debugging) and the 'Security Checklist' (Rubric).
  • Instructor Script:
    • "Thank you. You now have the 'final piece' of the puzzle: Security."
    • "In Module 09 (the E2E Review Module), we will 'summarize' everything, 'live debug' (hunt bugs), and 'assign' the Final Project with the full rubric (including the Security section)."
    • "See you then!"