Previously the same ip addresses would be computed for each nodePort
service and this could be CPU intensive for a large number of nodePort
services with a large number of ipaddresses on the node.
This commit adds support for using `gke-exec-auth-plugin` (vTPM-based
certificates for mTLS) for webhooks when calling endpoints matching
`*.googleapis.com`, and integrates this support with
ValidatingAdmissionWebhook.
To enable it, request ValidatingAdmissionWebhook with
`ADMISSION_CONTROL=...,ValidatingAdmissionWebhook,...` (default) and
opt in to `gke-exec-auth-plugin` using `WEBHOOK_GKE_EXEC_AUTH=true`
during the configuration process.
If you don't opt-in, ValidatingAdmissionWebhook will be deployed as
before.
Requesting `WEBHOOK_GKE_EXEC_AUTH=true` will fail if you have not
provided other configuration variables:
* `EXEC_AUTH_PLUGIN_URL`: controls whether `gke-exec-auth-plugin` is
downloaded during the installation step. A prerequisite for
actually using the plugin.
* `TOKEN_URL`, `TOKEN_BODY`, and `TOKEN_BODY_UNQUOTED`:
configuration values used when calling the plugin. `TOKEN_URL`
and `TOKEN_BODY` have existing usage. `TOKEN_BODY_UNQUOTED` is a
new variable that is meant to sidestep the problem of inverting
`strconv.Quote` in Bash.
The existing configuration process for ImagePolicyWebhook has been
reworked to make it play nicely with ValidatingAdmissionWebhook under
`WEBHOOK_GKE_EXEC_AUTH=true`.
* It originally placed the ImagePolicyWebhook configuration object
at the top-level of the file specified by
`--admission-control-config-file`. I can't see why this worked;
it must have been hitting some sort of lucky path through the
various config file loading mechanisms. Now, it places its
configuration in a sub-field of that file, which is shared among
all admission control plugins.
* It mounted its various config files read-write. I reviewed the
code and couldn't see why it was necessary, so I moved the config
files into the existing read-only mount at `/etc/srv/kubernetes`.
* It now checks that all the configuration values it requires have
been provided.
Co-authored-by: Mike Danese <mikedanese@google.com>
Co-authored-by: Taahir Ahmed <taahm@google.com>
Pod completes so fast the current check fails:
```
Jul 18 07:09:24.858: INFO: Running '/usr/bin/kubectl --server=https://api.ci-op-ziq360tf-12fbf.origin-ci-int-aws.dev.rhcloud.com:6443 --kubeconfig=/tmp/admin.kubeconfig run run-log-test --generator=run-pod/v1 --image=docker.io/library/busybox:1.29 --restart=OnFailure --namespace=e2e-tests-kubectl-nxzxx -- sh -c sleep 10; seq 100 | while read i; do echo $i; sleep 0.01; done; echo EOF'
...
Jul 18 07:09:25.116: INFO: Waiting up to 5m0s for pod "run-log-test" in namespace "e2e-tests-kubectl-nxzxx" to be "running and ready"
Jul 18 07:09:25.135: INFO: Pod "run-log-test": Phase="Pending", Reason="", readiness=false. Elapsed: 19.221661ms
...
Jul 18 07:09:57.456: INFO: Pod "run-log-test": Phase="Pending", Reason="", readiness=false. Elapsed: 32.339426605s
Jul 18 07:09:59.477: INFO: Pod "run-log-test": Phase="Succeeded", Reason="", readiness=false. Elapsed: 34.360446811s
...
Jul 18 07:14:24.023: INFO: Pod "run-log-test": Phase="Succeeded", Reason="", readiness=false. Elapsed: 4m58.906706065s
Jul 18 07:14:26.023: INFO: Pod run-log-test failed to be running and ready.
```
The test should be reporting running and ready or succeeded.
