"Here are the keys — drive safely."
In a Thin Wrapper approach, the platform team exposes the underlying Kubernetes API directly to developers. The developer writes standard Kubernetes YAML or Helm charts. The platform team's contribution is not a new interface — it is a set of guardrails that prevent dangerous or non-compliant configurations from being applied.
Think of it like a car rental company that gives you a real car with GPS pre-loaded and a speed limiter set to 90 mph. You still drive the car yourself. You still need a license.
The Interface: Standard Helm charts, raw Kubernetes YAML, or lightly templated manifests using tools like Kustomize.
The Guardrails: Policy-as-Code tools like OPA Gatekeeper or Kyverno enforce rules at admission time. Examples:
- No containers running as root (runAsNonRoot: true required)
- All images must come from the internal registry
- Resource limits (cpu, memory) must be set on every container
- No hostNetwork: true allowed
A Gatekeeper constraint that enforces resource limits looks like this:
# constraint.yaml — enforced by OPA Gatekeeper at admission time
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
name: require-resource-limits
spec:
match:
kinds:
- apiGroups: ["apps"]
kinds: ["Deployment"]
parameters:
limits: ["cpu", "memory"]
requests: ["cpu", "memory"]
When a developer tries to apply a Deployment without resource limits, the API server rejects it with a clear error message — before it ever reaches the scheduler.
Pros and Cons
Advantages:
- Maximum flexibility. If a developer needs to mount a GPU, configure a custom sidecar, or use an obscure sysctl setting, they can do it immediately without filing a ticket with the platform team.
- Standard tooling. Developers can use any Kubernetes tutorial, tool, or community resource directly. There is no proprietary layer to learn.
- Smaller platform team surface area. The platform team maintains policies and cluster configuration, not a custom software product.
Disadvantages:
- High cognitive load. Every developer must learn Kubernetes concepts: pods, services, ingress controllers, RBAC, resource requests vs. limits. Onboarding takes weeks, not hours.
- Configuration drift. Without strict templates, every team's deployment YAML looks slightly different. Debugging becomes harder because there is no canonical structure.
- Inconsistent best practices. A developer who doesn't know about PodDisruptionBudgets simply won't use them — and the platform won't enforce them unless the policy team explicitly writes a rule.
Interviewers often ask: "How do you enforce security standards in a Kubernetes cluster without blocking developer velocity?" The answer is Policy-as-Code with tools like OPA Gatekeeper or Kyverno. The key insight: enforcement happens at the Kubernetes admission webhook layer, so policies are applied consistently regardless of how the manifest was created (kubectl, Helm, CI/CD pipeline, or Terraform). Mention that policies should be in warn mode before deny mode to avoid surprise breakage.