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>
