Internal service platform

Context

• Internal tools accumulate. Each one is deployed slightly differently, secured slightly differently, and maintained by whoever built it.
• Security review becomes the bottleneck because every service presents a new shape.

What was actually wrong

• Per-service bespoke infrastructure means per-service bespoke risk, and the risk is discovered late.
• Access control bolted on afterwards tends to be access control that can be bypassed.

Approach

1. 01Standardise the deployment unit: one container contract, one build pipeline, one runtime configuration shape.
2. 02Put identity in front of everything by default, verified at the edge, with the service also validating the signed assertion rather than trusting a header.
3. 03Least-privilege runtime identity per service, provisioned as code so it is reviewable.
4. 04Codify the infrastructure so onboarding a service is a reviewed change to a declared configuration, not a console session nobody witnessed.
5. 05Make the safe path the easy path. Standards that are harder than the workaround do not survive contact with a deadline.

Architecture

• Containerised services on managed serverless compute
• Identity-aware proxy in front, with cryptographic assertion verification in the service
• Infrastructure as code for identity, networking, DNS and service registration
• CI/CD with environment separation and reproducible builds

What this demonstrates

• Platform thinking: solving a class of problem once instead of each instance repeatedly
• Security designed in at the boundary rather than appended
• Operational empathy for the teams who have to use the standard

Related