Service-to-service authorization
On This Lesson 4 topics
This lesson is planned. The outline below lists the topics it will cover. The full lesson has not been published yet.
In this lesson
choose mechanisms for service identity and authorization.
Planned topics
- Workload identity: each service gets its own identity issued by the platform (for example SPIFFE-style identities); verify which standard and tooling you use before recording.
- mTLS authenticates both ends and encrypts traffic; a service mesh can automate certificate rotation.
- Scoped tokens carry what a caller may do (audience, scopes), kept short-lived.
- Authorization decides at the callee: allow-lists of caller identities per endpoint, with business rules in a policy layer.
- Avoid shared credentials between teams; one service, one identity.
Draft outline details
Demonstration
An authorization matrix: caller identity | endpoint or event topic | action allowed. Example: fulfillment-service may read Shop order events; may not read payment data.
Check your understanding
Why avoid shared credentials between teams?
Show answer
You cannot tell who did what, and a leak exposes every user of the credential.
Practice
Apply this lesson with the module's lab, exercises and quiz.
Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.