Before
- Every product has its own login logic
- Audit fields differ by product
- Security teams review five auth implementations
Module 1 of 8
Google-Style Login for Many Kubernetes Products
Start with the Gmail, YouTube, and Google mental model: one account, many products, consistent identity.
Start here
Learning objectives
- Explain centralized authentication using the explicit Google, Gmail, and YouTube example
- Map the same idea to Kubernetes products behind a shared Envoy edge
- Separate login, token validation, authorization, and product-specific permissions
- Decide what should be centralized and what should stay inside each product
After
- Envoy enforces a shared identity contract
- Products receive consistent identity context
- Security teams review one central pattern plus product-specific permissions
The Beginner Mental Model
When you log in to Google once, you can open Gmail, YouTube, Drive, Calendar, and other Google products without signing in again for every product. That does not mean every product has the same permissions. It means there is a shared identity system and each product can trust who you are.
We want the same idea for a Kubernetes platform. A company may run a developer portal, data explorer, admin UI, reporting service, internal API, and job runner. Without a central design, every product adds its own login page, token parser, permission code, and audit format. That creates duplicate bugs and inconsistent security.
The Kubernetes Version
Put plain Envoy at the platform edge. Envoy receives traffic first, checks the request, validates what it can locally, asks a central authorization service when policy needs a decision, and only then forwards the request to the product service.
The product still owns business rules such as "can this user delete this invoice?" or "can this analyst open this table?" Envoy owns the shared front-door checks: is there a valid identity, is the token from a trusted issuer, is the audience correct, is the request allowed to reach this product, and what identity context should be forwarded.
What Gets Centralized
- Login and SSO entry points for humans.
- JWT validation with trusted issuers and JWKS keys.
- Service-token validation for machines.
- Basic route-level authorization such as product, tenant, environment, or role.
- Audit context such as user ID, service ID, request ID, tenant, and policy decision.
What Should Not Be Centralized Blindly
Do not move every business rule to the edge. Envoy should not know every data row, invoice state, or product-specific workflow. Centralize cross-product policy and identity enforcement. Keep domain-level authorization close to the service that owns the data.
First Architecture Sketch
Start with this simple flow: user or service sends a request, Envoy checks identity, Envoy asks an auth service when the decision is not purely local, then the product receives a trusted request with identity context.
Real world
Where this shows up
- A Kubernetes platform with many internal products that should share one login and one enforcement layer
- Developer portals, data tools, admin consoles, APIs, and service-to-service calls protected at the edge
- Migration from product-specific auth logic to centralized policy checks without rewriting every product first
Production notes
Keep these close
- Use one platform identity contract so every product receives identity context in the same shape
- Start with a small product set before migrating every internal application
- Write down which authorization checks are central and which remain product-owned
Common mistakes
What usually breaks
- Confusing centralized login with centralized ownership of every permission
- Letting each product parse identity differently
- Forwarding raw tokens to every product when only verified identity context is needed
Security risks
Threats to watch
- One weak product-specific auth implementation can become a platform-wide entry point
- Inconsistent audit fields make incident response slow
- Over-centralized policy can accidentally grant access to data the policy service does not understand
Tradeoffs
Design choices you should be able to defend
Central Envoy enforcement
Pros
- Consistent identity checks
- One place for common policy
- Easier audit and migration
Cons
- Envoy and the auth service become critical path components
- Bad central policy can affect many products
Each product owns all auth
Pros
- Simple for one product
- Product team has full control
Cons
- Duplicated logic
- Inconsistent security
- Harder to audit and scale across products
Think like an engineer
Questions to answer before shipping
- Which identity is making the request: a human, a service, or a federated cloud principal?
- Which check belongs at Envoy, and which check must remain inside the product domain model?
- What happens when the identity provider, JWKS endpoint, or auth service is slow or unavailable?
Key terms
Vocabulary used in this module
Authentication
Proving who or what is making the request.
Authorization
Deciding what that identity is allowed to do.
SSO
Single sign-on; a user logs in once and can access multiple trusted products.
Envoy
A high-performance proxy often used as an API gateway, edge proxy, or service mesh data plane.
Exercises
Practice inside the lesson
Draw the Product Map
Create a beginner-friendly platform map with five products and one central Envoy auth entry point.
- List five Kubernetes products: dashboard UI, data explorer, admin console, job API, and reporting service
- Mark which products need browser SSO
- Mark which products need API access tokens
- Mark which products need service-to-service tokens
- Draw Envoy in front and label which checks happen centrally
Recap
Key takeaways
- The Google analogy is one login and many products, not one permission model for everything
- Plain Envoy is a strong central enforcement point for Kubernetes products
- Products still own business authorization decisions that depend on product data
Related resources