Lead: Greg Castle
How are people using k8s service accounts
Default service accounts?
Only allow pre-set service accounts postgres “operator service accounts”
Don’t enable RBAC
Namespaces: usually use the default namespace, more sophisticated clients can use namespaces
Cluster per product
CRD that defines request for an OAuth2 token
Strict way of “cutting up cluster”
No team has access to the Kubernetes API
Humans do, pods don’t
Admins create service accounts and role bindings
Issues with pod authors in the namespace can run any service account.
Projects are per-namespace (200 namespaces)
Wrote an admission controller between which pod is using which service account. Denies certain kind of changes.
Ownership model “I created this object, only I can change it”
Namespace but wanted sub-namespace primitives
Service accounts have labels, need to match the pod.
Q: Why not just different namespaces?
Dev, staging, and prod cluster
Namespace per team
Their developers don’t have permissions to create workloads
CI system is the thing that creates workloads, that controls stuff
Customers create namespaces that are controlled by CI/CD
Users have read-access to cluster
Central catalog controls the service account
Authoritative on RBAC
Catalog is currently controlled by CoreOS, can be used by users later
Also use service accounts to authenticate CI/CD systems
Authenticate workloads against each other
Does this fit into the current way you use service accounts?
What about envoy istio?
Services can do service to service auth
Maybe not solving “I want to talk to s3, I want to talk to GitHub”
Give them a better way to provision x509 certs
Istio and SPIFFE?
Q: how does Zalando RBAC CRDs?
Trust two engineers that have the permissions to create the CRDs
Emergency procedure with time limited API
Q: multiple clusters working together?
IBM: going to face it
CoreOS: thinking about users authenticating across multiple clusters through sharing public keys.
Liggitt: namespaces are the boundaries of trust
Originally thought about using pod templates so admins could create specific templates that pods MUST use.
Reference pod template in RC or deployment instead of inlining them
Liggitt: Kubernetes API isn’t really designed for things that hold credentials
Moving the mounting and creation of the service account to the kubelet through flex volumes
Helps you leverage the node level integrations
Q: what about the secrets proposal?
KMS is being added
No change for encrypting the secret as you read it
Authorization should apply to the identity, rather than the namespace
Is multiple SA per namespace an anti-pattern?
Useful for bounding process within pods to certain permissions
Problem when a SA from cluster scoped manifests
Q: kerberos and vault bindings implemented as flex volumes
Is it important to have standard identity mechanisms? (Yes)
Can we add it to conformance?
Avoid lock-in for IAM
Cluster identity also becomes an issue too
Potentially use OpenID Connect format so others can use that spec