Add ConfigMapSyncer controller and rukpak-ca configmap

[joelanford]

The ConfigMapSyncer syncs secret data to configmaps based on injection
annotations present in configmaps in watched namespaces.

We include a rukpak-ca configmap with these annotations present so
that cluster administrators can share rukpak-ca trust without
exposing the CA key that's present in the rukpak-ca secret.

Closes #475

Signed-off-by: Joe Lanford joe.lanford@gmail.com

[joelanford]

/hold cancel

[joelanford]

The controller-runtime multi-namespace cache builder PR has not merged yet, so I've refactored this PR to:

1. Not require that PR
2. Include a TODO comment to update our repo if/when that PR merges

[joelanford]

This PR is two steps forward, but one step back:

1. Two steps forward
   • we're using configmaps instead of secrets in rukpakctl, so cluster admins don't have to give secret read permission to rukpakctl users.
   • we're making the build of rukpakctl more flexible so that its defaults can be reconfigured if vendors deploy rukpak with a different configuration.
2. One step back:
   • The ConfigMapSyncer (and the e2e test that accompanies it) solves an upstream problem we have using cert-manager to manage rukpak secrets. But rukpak doesn't directly depend on cert-manager, it depends on having certs in the right places. Other deployments of rukpak might use different certificate managers that don't share assumptions made by the ConfigMapSyncer (e.g. the CA bundle might not be in a secret in the rukpak system namespace).

Therefore
/hold
The step back is giving me some pause, and I think we should discuss how to handle it. Two thoughts:

1. Put the ConfigMapSyncer in a separate controller that rukpak distros can simply decide not to include.
2. Leave the ConfigMapSyncer in the core controller, but make it possible to disable it somehow (flag at runtime, build flag that straight up removes the code?)

[openshift-merge-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.