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