forked from hswaw/hscloud
27 lines
1.4 KiB
Markdown
27 lines
1.4 KiB
Markdown
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`.
|