Commit Graph

5 Commits

Author SHA1 Message Date
Ryan Richard
80153f9a80 Allow app to start despite failing to borrow the cluster signing key
- Controller and aggregated API server are allowed to run
- Keep retrying to borrow the cluster signing key in case the failure
  to get it was caused by a transient failure
- The CredentialRequest endpoint will always return an authentication
  failure as long as the cluster signing key cannot be borrowed
- Update which integration tests are skipped to reflect what should
  and should not work based on the cluster's capability under this
  new behavior
- Move CreateOrUpdateCredentialIssuerConfig() and related methods
  to their own file
- Update the CredentialIssuerConfig's Status every time we try to
  refresh the cluster signing key
2020-08-25 18:22:53 -07:00
Ryan Richard
6e59596285 Upon pod startup, update the Status of CredentialIssuerConfig
- Indicate the success or failure of the cluster signing key strategy
- Also introduce the concept of "capabilities" of an integration test
  cluster to allow the integration tests to be run against clusters
  that do or don't allow the borrowing of the cluster signing key
- Tests that are not expected to pass on clusters that lack the
  borrowing of the signing key capability are now ignored by
  calling the new library.SkipUnlessClusterHasCapability test helper
- Rename library.Getenv to library.GetEnv
- Add copyrights where they were missing
2020-08-24 18:07:34 -07:00
Ryan Richard
3929fa672e Rename project 2020-08-20 10:54:15 -07:00
Matt Moyer
1b9a70d089
Switch back to an exec-based approach to grab the controller-manager CA. (#65)
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>
2020-08-19 13:21:07 -05:00
Ryan Richard
4cb0fd3949 Use a DaemonSet instead of a Deployment to deploy our app
- For high availability reasons, we would like our app to scale linearly
  with the size of the control plane. Using a DaemonSet allows us to run
  one pod on each node-role.kubernetes.io/master node.
- The hope is that the Service that we create should load balance
  between these pods appropriately.
2020-08-11 17:55:34 -07:00