Running as non-root prevents authenticator from writing to host path

[baniol]

Build from v0.2.0-pre tag. Container running as a non-root user.

Pod is crashing because it can't write kubeconfig to a host folder:

time="2018-02-04T20:17:58Z" level=info msg="writing webhook kubeconfig file" kubeconfigPath=/srv/kubernetes/heptio-authenticator-aws/kubeconfig.yaml
time="2018-02-04T20:17:58Z" level=fatal msg="could not write kubeconfig" error="open /srv/kubernetes/heptio-authenticator-aws/kubeconfig.yaml: permission denied" kubeconfigPath=/srv/kubernetes/heptio-authenticator-aws/kubeconfig.yaml

[mumoshu]

Hi, @baniol!

Probably this is a documentation issue as what you see itself is more or less how docker works.

You should specify the uid of the init process of the container to one of the user has write access to any volume. Otherwise, it just fails to write, which is what you see.

So, assuming you're using minikube, would you mind confirming if this works?

docker run -u $(minikube ssh 'sh -c "id -u $USER"' | tr -d "\r") -v $(pwd)/work:/work -w /work gcr.io/heptio-images/authenticator:v0.2.0-pre init --cluster-id foo

whereas an expected result should be:

time="2018-03-19T03:33:54Z" level=info msg="loaded existing keypair" certPath=cert.pem keyPath=key.pem
time="2018-03-19T03:33:54Z" level=info msg="loaded existing keypair" certPath=cert.pem keyPath=key.pem
time="2018-03-19T03:33:54Z" level=info msg="writing webhook kubeconfig file" kubeconfigPath=heptio-authenticator-aws.kubeconfig
time="2018-03-19T03:33:54Z" level=info msg="copy cert.pem to /var/heptio-authenticator-aws/cert.pem on kubernetes master node(s)"
time="2018-03-19T03:33:54Z" level=info msg="copy key.pem to /var/heptio-authenticator-aws/key.pem on kubernetes master node(s)"
time="2018-03-19T03:33:54Z" level=info msg="copy heptio-authenticator-aws.kubeconfig to /etc/kubernetes/heptio-authenticator-aws/kubeconfig.yaml on kubernetes master node(s)"
time="2018-03-19T03:33:54Z" level=info msg="configure your apiserver with `--authentication-token-webhook-config-file=/etc/kubernetes/heptio-authenticator-aws/kubeconfig.yaml` to enable authentication with heptio-authenticator-aws"

[chrisduong]

Hi, I had tried this in KOPS cluster. I had pre-generated the Configuration files, then faced the same problem (This time with default Root user). The Pod in the example.yaml will run as root user, same as the user when I had pre-genrated the configuration files for the webhook. It is supposed to be able to write. However, it failed with the same above error

I discovered that there is a flag option --kubeconfig-pregenerated=true, which mean set to true when a webhook kubeconfig is pre-generated by running the initcommand, and therefore theserver shouldn't unnecessarily re-generate a new one.

I'm using version 0.3.0, this version will auto-genrate the configuration files in server mode. You can try to this flag, it would solve this problem.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.