Currently if you split the extension into two binaries (one for registering the webhook and the other for running the mutating webhook webserver), and do not add a k8s api token to the server container, then it fails to start.
The k8s api permissions needed to get the webserver to start currently are:
Secrets: GET (used for getting the server certificate)
Namespaces: GET, UPDATE (used for updating namespace labels)
This feature request is to allow running the server container no k8s api service token. The server container could skip creating a k8s connection and updating the namespace labels if the RegisterWebhooks flag is false.
It will still need a webhook server cert, but this could be provided as a secret mounted as a volume instead.
Currently if you split the extension into two binaries (one for registering the webhook and the other for running the mutating webhook webserver), and do not add a k8s api token to the server container, then it fails to start.
The k8s api permissions needed to get the webserver to start currently are: Secrets: GET (used for getting the server certificate) Namespaces: GET, UPDATE (used for updating namespace labels)
This feature request is to allow running the server container no k8s api service token. The server container could skip creating a k8s connection and updating the namespace labels if the RegisterWebhooks flag is false. It will still need a webhook server cert, but this could be provided as a secret mounted as a volume instead.
Additional context: https://cloudfoundry.slack.com/archives/CNBSLS8CW/p1585588796005700
Related code: Finding the webhook server cert in a secret: https://github.com/SUSE/eirinix/blob/d1a681d5d353568fc55af402f87e17f6ef3704bb/webhook_configuration.go#L75-L102 Updating namespace labels: https://github.com/SUSE/eirinix/blob/fd343f4e20566d66f8e60f41296482b53d661722/manager.go#L323-L335