1
0
Fork 0
hscloud/cluster/prodaccess
q3k 0f8e5a2132 *: do not require env.sh
This removes the need to source env.{sh,fish} when working with hscloud.

This is done by:

 1. Implementing a Go library to reliably detect the location of the
    active hscloud checkout. That in turn is enabled by
    BUILD_WORKSPACE_DIRECTORY being now a thing in Bazel.
 2. Creating a tool `hscloud`, with a command `hscloud workspace` that
    returns the workspace path.
 3. Wrapping this tool to be accessible from Python and Bash.
 4. Bumping all users of hscloud_root to use either the Go library or
    one of the two implemented wrappers.

We also drive-by replace tools/install.sh to be a proper sh_binary, and
make it yell at people if it isn't being ran as `bazel run
//tools:install`.

Finally, we also drive-by delete cluster/tools/nixops.sh which was never used.

Change-Id: I7873714319bfc38bbb930b05baa605c5aa36470a
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1169
Reviewed-by: informatic <informatic@hackerspace.pl>
2021-10-17 21:21:58 +00:00
..
BUILD.bazel *: do not require env.sh 2021-10-17 21:21:58 +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 *: developer machine HSPKI credentials 2020-08-01 17:15:52 +02:00

README.md

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.