hscloud/cluster/prodaccess/README.md
Sergiusz Bazanski b13b7ffcdb prod{access,vider}: implement
Prodaccess/Prodvider allow issuing short-lived certificates for all SSO
users to access the kubernetes cluster.

Currently, all users get a personal-$username namespace in which they
have adminitrative rights. Otherwise, they get no access.

In addition, we define a static CRB to allow some admins access to
everything. In the future, this will be more granular.

We also update relevant documentation.

Change-Id: Ia18594eea8a9e5efbb3e9a25a04a28bbd6a42153
2019-08-30 23:08:18 +02:00

26 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`.