going to try to set up clusters and have to deal with this. • “Dealing with this” can range from: ◦ Whitelisting some set of nodes. ◦ Multi-tenant environments.
really true, but I find it easier to think this way. • “Users” are just strings associated with a request through credentials. ◦ Username=eric ◦ Groups=[“developer”, “gopher”]
ca.crt: ( LOT OF DATA ) namespace: ZGVmYXVsdA== token: ( JSON web token signed by API server) kind: Secret type: kubernetes.io/service-account-token metadata: # ... Users in Kubernetes: service accounts
(and an associated user) for talking to the API server. • Only way to create users through the API. ◦ Credentials stored in secrets, be careful! • Can be used from outside the cluster. Users in Kubernetes: service accounts
subject, verb, resource, and namespace. ◦ User A can create pods in namespace B. • Cannot: ◦ Refer to a single object in a namespace. ◦ Refer to arbitrary fields in a resource. • Can: ◦ Refer to subresources (e.g. nodes/status)
Group # May be "User", "Group" or "ServiceAccount" name: manager roleRef: kind: ClusterRole name: secret-reader apiVersion: rbac.authorization.k8s.io/v1alpha1 RBAC: Role Bindings
cluster level or a namespace level. • Cluster role: ◦ Manage one set of roles for your entire cluster. • Role: ◦ Allow “namespace admins” to admin roles just for a namespace.
the power of a role to bind a user to that role. ◦ If you don’t have the ability to create secrets, you can’t give someone else that power. • Currently get around this with a bootstrapping flag that lets a user sidestep this.
@deads2k (RedHat). • Biggest highlight: default roles and role bindings! ◦ Extremely helpful for bootstrapping. ◦ Can mint x509 cert for “cluster-admin” to bootstrap cluster.