- The certs manager controller, along with its sibling certs expirer
and certs observer controllers, are generally useful for any process
that wants to create its own CA and TLS certs, but only if the
updating of the APIService is not included in those controllers
- So that functionality for updating APIServices is moved to a new
controller which watches the same Secret which is used by those
other controllers
- Also parameterize `NewCertsManagerController` with the service name
and the CA common name to make the controller more reusable
- Upgrade from `1.19.0-rc.0` to the newly-release `1.19.0`.
- Downgrade from `1.18.6` to `1.18.2` to match some downstream consumers.
Signed-off-by: Matt Moyer <moyerm@vmware.com>
This should simplify our build/test setup quite a bit, since it means we have only a single module (at the top level) with all hand-written code. I'll leave `module.sh` alone for now but we may be able to simplify that a bit more.
Signed-off-by: Matt Moyer <moyerm@vmware.com>
This switches us back to an approach where we use the Pod "exec" API to grab the keys we need, rather than forcing our code to run on the control plane node. It will help us fail gracefully (or dynamically switch to alternate implementations) when the cluster is not self-hosted.
Signed-off-by: Matt Moyer <moyerm@vmware.com>
Co-authored-by: Ryan Richard <richardry@vmware.com>
- Also includes bumping the api and client-go dependencies to the newer
version which also moved LoginDiscoveryConfig to the
crds.placeholder.suzerain-io.github.io group in the generated code
Add initial aggregated API server (squashed from a bunch of commits).
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Signed-off-by: Aram Price <pricear@vmware.com>
Signed-off-by: Ryan Richard <richardry@vmware.com>
- Users may want to consume pkg/config to generate configuration files.
- This also involved putting config-related utilities in the config
package for ease of consumption.
- We did not add in versioning into the Config type for now...this is
something we will likely do in the future, but it is not deemed
necessary this early in the project.
- The config file format tries to follow the patterns of Kube. One such
example of this is requiring the use of base64-encoded CA bundle PEM
bytes instead of a file path. This also slightly simplifies the config
file handling because we don't have to 1) read in a file or 2) deal
with the error case of the file not being there.
- The webhook code from k8s.io/apiserver is really exactly what we want
here. If this dependency gets too burdensome, we can always drop it,
but the pros outweigh the cons at the moment.
- Writing out a kubeconfig to disk to configure the webhook is a little
janky, but hopefully this won't hurt performance too much in the year
2020.
- Also bonus: call the right *Serve*() function when starting our
servers.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
