prodvider
It provides access, yo.
Architecture
Prodvider uses an intermedaite CA (the prodvider CA, signed by the kube CA), to generate the following:
- a cert for prodvider to present itself over gRPC for prodaccess clients
- a cert for prodvider to authenticate itself to the kube apiserver
- client certificates for prodaccess consumers.
Any time someone runs 'prodaccess', they get a certificate from the intermediate CA, and the intermediate CA is included as part of the chain that they receive. They can then use this chain to authenticate against kubernetes.
Naming
Prodvider customers get certificates with a CN=username@hackerspace.pl
and O=sso:username
. This means that they appear to Kubernetes as being a User
named username@hackerspace.pl
and Group
named sso:username
. In the future, another group might be given to users, do not rely on this relationship.
Kubernetes Structure
After generating a user certificate, prodvider will also call kubernetes to set up a personal user namespace (personal-username
), a RoleBinding to system:admin-namespace
from their User
in their namespace (thus, giving them full rights in it) and a ClusterRoleBinding to system:viewer
from their User
(thus, giving them some read access for all resources, but not to secure data (like secrets).
system:admin-namespace
and system:viewer
are defined in //cluster/kube
.