Blueprint for delegated IaC via the operator #65024
Description
Problem statement
Large customers security teams are turning into bottlenecks as many teams in their company need to configure Teleport for their usage (add tokens, roles, access lists, ...). Every team has its own process, RBAC, CI/CD pipeline, ...
Security teams want to stay out of the way of their users while still enforcing security invariants. Centralizing everything into one giant Terraform pipeline is often not an option for those large scale cross-team deployments.
Solution
Several customers naturally converged to one pattern: using Kubernetes CRDs as an interface for every team to autonomously create/manage their Teleport resources. This allows them to:
- provide and control access to IaC kube namespaces via Teleport itself
- use the existing Kubernetes tools to apply policies (e.g. label, resource prefix, no secret token, ...):
- Best getting started: native Kubernetes Admission Policies: https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/
- More advanced setups: Kyverno, Gatekeeper, Kubewarden
- Ability to let AI tools configure Teleport in a restricted environment
This whole pattern is currently already being set-up by our largest customers. Several security teams independently came to the conclusion this was the best approach for their use-case.
We can make it easier and encourage it by doing small changes to the operator (multi-namespace support), and documenting the pattern through a blueprint or a step-by-step guide.
Notes
- Scopes solve this from a security pov, but the IaC is still centralized in one place. Scopes has an excellent synergy with the suggested feature. You can write policies to enforce the scope name to match the namespace.
- Accesslists solve part of this pain by allowing to delegate role grants. However teams still require to perform many operations such as creating tokens, bots, access monitoring rules, ...