Fork 0
q3k 97b5cd7b58 go: re-do the entire thing
This is a mega-change, but attempting to split this up further is
probably not worth the effort.


1. Bump up bazel, rules_go, and others.
2. Switch to new go target naming (bye bye go_default_library)
3. Move go deps to go.mod/go.sum, use make gazelle generate from that
4. Bump up Python deps a bit

And also whatever was required to actually get things to work - loads of
small useless changes.

Tested to work on NixOS and Ubuntu 20.04:

   $ bazel build //...
   $ bazel test //...

Change-Id: I8364bdaa1406b9ae4d0385a6b607f3e7989f98a9
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1583
Reviewed-by: q3k <q3k@hackerspace.pl>
2023-09-22 21:50:19 +00:00
BUILD.bazel go: re-do the entire thing 2023-09-22 21:50:19 +00:00
README.md prod{access,vider}: implement 2019-08-30 23:08:18 +02:00
hspki.go go/pki: fix error return 2021-05-19 22:12:08 +00:00
kubernetes.go *: do not require env.sh 2021-10-17 21:21:58 +00:00
prodaccess.go go: re-do the entire thing 2023-09-22 21:50:19 +00:00



It provides access, yo.


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.


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.