- [[#Core Principles|Core Principles]] - [[#Five Functions of Cybersecurity (NIST)|Five Functions of Cybersecurity (NIST)]] - [[#Credentials|Credentials]] - [[#Credentials#Never Store Secrets in Source Code|Never Store Secrets in Source Code]] - [[#Credentials#Current Implementation|Current Implementation]] - [[#Patching|Patching]] - [[#Backups|Backups]] - [[#Backups#The "Schrodinger Backup"|The "Schrodinger Backup"]] - [[#Implicit Trust vs Zero Trust|Implicit Trust vs Zero Trust]] - [[#Implicit Trust vs Zero Trust#Zero Trust Principles|Zero Trust Principles]] - [[#Securing Data|Securing Data]] - [[#Securing Data#Data in Transit|Data in Transit]] - [[#Securing Data#Data at Rest|Data at Rest]] - [[#Authentication & Authorization|Authentication & Authorization]] - [[#Authentication & Authorization#Service-to-Service|Service-to-Service]] - [[#Authentication & Authorization#Human Authentication|Human Authentication]] - [[#Authentication & Authorization#Single Sign-On (SSO)|Single Sign-On (SSO)]] - [[#JSON Web Tokens (JWT)|JSON Web Tokens (JWT)]] - [[#JSON Web Tokens (JWT)#What JWTs Provide|What JWTs Provide]] - [[#JSON Web Tokens (JWT)#JWT Structure|JWT Structure]] - [[#JSON Web Tokens (JWT)#JWT for Microservices|JWT for Microservices]] - [[#The Confused Deputy Problem|The Confused Deputy Problem]] - [[#The Confused Deputy Problem#The Problem|The Problem]] - [[#The Confused Deputy Problem#The Solution|The Solution]] - [[#How MusicCorp Compares to Chapter 11 Recommendations|How MusicCorp Compares to Chapter 11 Recommendations]] - [[#Action Items for MusicCorp|Action Items for MusicCorp]] - [[#Action Items for MusicCorp#High Priority|High Priority]] - [[#Action Items for MusicCorp#Medium Priority|Medium Priority]] - [[#Action Items for MusicCorp#Lower Priority|Lower Priority]] - [[#Discussion Questions|Discussion Questions]] - [[#Key Quotes|Key Quotes]] - [[#Recommended Reading|Recommended Reading]] ## Core Principles - Security is everyone's responsibility - Defense in depth: multiple layers of protection - Principle of least privilege - Fail securely --- ## Five Functions of Cybersecurity (NIST) | Function | Purpose | Example in MusicCorp | |----------|---------|---------------------| | **Identify** | Know your assets and risks | Service inventory, data classification | | **Protect** | Implement safeguards | TLS, authentication, authorization | | **Detect** | Discover security events | Logging, monitoring, alerting | | **Respond** | Take action on incidents | Incident playbooks, alerting | | **Recover** | Restore capabilities | Backups, disaster recovery | --- ## Credentials ### Never Store Secrets in Source Code **Anti-patterns:** ```python # DON'T DO THIS DATABASE_PASSWORD = "supersecret123" API_KEY = "sk_live_abc123" ``` **Better approaches:** | Method | Description | MusicCorp Status | |--------|-------------|------------------| | Environment variables | Injected at runtime | Done (K8s Secrets) | | Secret management | Vault, AWS Secrets Manager | Not implemented | | Short-lived credentials | IAM roles, service accounts | Not implemented | ### Current Implementation ```yaml # MusicCorp uses K8s Secrets env: - name: DATABASE_URL valueFrom: secretKeyRef: name: postgres-secret key: ORDER_DATABASE_URL ``` **Improvement needed:** Secrets are base64 encoded, not encrypted. Production should use: - External secrets operator - Vault integration - AWS Secrets Manager with External Secrets --- ## Patching - Keep systems up to date - Automate patching where possible - Prioritize based on severity and exposure **In MusicCorp:** - Base images should be updated regularly - Dependabot or Renovate for dependency updates - CVE scanning in CI (Trivy, Snyk) --- ## Backups ### The "Schrodinger Backup" > An untested backup might not work. You won't know until you try to restore. **Best practices:** - Test restores regularly - Store backups separately (different accounts, regions) - Encrypt backup data **MusicCorp gaps:** - No automated PostgreSQL backups - No backup testing - Single availability zone --- ## Implicit Trust vs Zero Trust | Implicit Trust | Zero Trust | |----------------|------------| | Trust inside perimeter | Trust nothing | | Simpler but risky | More secure but complex | | Common default | Requires investment | ### Zero Trust Principles 1. **Verify explicitly**: Always authenticate and authorize 2. **Least privilege**: Minimum access needed 3. **Assume breach**: Design for when, not if **MusicCorp status:** - Services trust each other (no auth between services) - Database credentials are per-service (good!) - No mTLS between services --- ## Securing Data ### Data in Transit Four concerns: | Concern | Solution | MusicCorp Status | |---------|----------|------------------| | **Server Identity** | TLS certificates | Ingress only | | **Client Identity** | Mutual TLS (mTLS) | Not implemented | | **Visibility** | Encrypt traffic | Internal traffic unencrypted | | **Manipulation** | TLS, HMAC | Ingress only | **Recommendation:** Consider service mesh (Istio, Linkerd) for automatic mTLS between services. ### Data at Rest **Best practices:** - Use well-known encryption libraries (never roll your own) - Salted password hashing for credentials - Pick your targets: encrypt sensitive data - Be frugal with data collection (Datensparsamkeit) - Key management is critical (use Vault, HSMs) - Encrypt backups too **MusicCorp status:** - PostgreSQL data not encrypted at rest (in Kind cluster) - No PII encryption beyond transport - Customer emails stored in plain text --- ## Authentication & Authorization ### Service-to-Service | Method | Description | MusicCorp Status | |--------|-------------|------------------| | **Mutual TLS (mTLS)** | Both sides verify certificates | Not implemented | | **API keys** | Static tokens | Not implemented | | **JWT tokens** | Signed claims | Not implemented | | **Service mesh** | Automatic mTLS | Not implemented | **Current state:** Services communicate without authentication. ### Human Authentication | Factor Type | Examples | |-------------|----------| | **Something you know** | Password, PIN | | **Something you have** | Phone, hardware key | | **Something you are** | Fingerprint, face | **MFA should be required for:** - Admin access to infrastructure - Production deployments - Secret management ### Single Sign-On (SSO) - One login for multiple services - Identity provider handles authentication - OpenID Connect (OIDC) is the dominant standard **MusicCorp:** No user authentication implemented yet. --- ## JSON Web Tokens (JWT) ### What JWTs Provide - Signed tokens containing claims about identity - Stateless: microservices can validate without calling identity service - Contains: header, payload, signature ### JWT Structure ``` eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE1MTYyMzkwMjJ9. SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c ``` | Part | Contains | |------|----------| | Header | Algorithm, token type | | Payload | Claims (user ID, roles, expiration) | | Signature | HMAC or RSA signature | ### JWT for Microservices ``` Client → API Gateway → Order Service → Inventory Service (validates) (passes JWT) (validates claims) ``` **Considerations:** - Key management (shared secrets vs RSA) - Token expiration (short-lived is safer) - Token size (claims add up) - Revocation is hard (tokens are stateless) --- ## The Confused Deputy Problem ### The Problem An intermediate service (deputy) is tricked into acting with authority it shouldn't have. ``` Attacker → Order Service → Inventory Service (deputy) (trusts Order) ``` Attacker convinces Order to make requests to Inventory that Order wouldn't normally make. ### The Solution Pass identity context through the call chain: ``` Client → Order Service → Inventory Service JWT → (passes JWT) → (validates original user) ``` Decentralize authorization decisions to the service owning the data. --- ## How MusicCorp Compares to Chapter 11 Recommendations | Book Recommendation | Our Implementation | Status | |---------------------|-------------------|--------| | **Secrets management** | K8s Secrets | Partial | | **mTLS between services** | Not implemented | Gap | | **Data encryption at rest** | Not implemented | Gap | | **User authentication** | Not implemented | Gap | | **Service-to-service auth** | Not implemented | Gap | | **JWT propagation** | Not implemented | Gap | | **Backup encryption** | No backups | Gap | | **CVE scanning** | Not in CI | Gap | | **Audit logging** | Basic structured logs | Partial | --- ## Action Items for MusicCorp ### High Priority 1. **Add CVE scanning to CI** - Trivy for container images - Dependabot for dependencies 2. **Implement external secrets** - AWS Secrets Manager or Vault - External Secrets Operator ### Medium Priority 1. **Add user authentication** - OAuth2/OIDC with identity provider - JWT token validation at API gateway 2. **Consider service mesh** - Automatic mTLS between services - Istio or Linkerd ### Lower Priority 1. **Encrypt data at rest** - PostgreSQL encryption - Kafka message encryption 2. **Add backup automation** - PostgreSQL backups to S3 - Test restore procedures --- ## Discussion Questions 1. **Service-to-service auth**: We currently have no auth between services. Is this acceptable for a learning project? When would we need it? 2. **JWT vs API keys**: For service-to-service auth, would you prefer JWT tokens or simple API keys? 3. **Secret rotation**: How would we rotate database passwords without downtime? 4. **Zero trust cost**: Full zero trust requires significant investment. How do you prioritize what to implement first? 5. **The confused deputy**: Could an attacker exploit the lack of auth between our services? What's the attack vector? --- ## Key Quotes > "Security is everyone's responsibility, not just the security team's." > "Defense in depth means assuming each layer of security might fail." > "The confused deputy problem occurs when an intermediate service is tricked into acting with authority it shouldn't have." > "Zero trust: verify explicitly, use least privilege, assume breach." --- ## Recommended Reading - OWASP Top 10: <https://owasp.org/Top10/> - NIST Cybersecurity Framework: <https://www.nist.gov/cyberframework> - "Zero Trust Networks" by Evan Gilman and Doug Barth