*: fix cert and env binding for k8s-node-boostrapper

[squat]

Cherry-pick #2460 into track-1
Fixes: https://jira.coreos.com/browse/INST-859

This change adds a bindmount of /etc/ssl
It will also load /etc/profile.env into the env to
The /etc/profile.env file is populated by ignition
based on: https://tinyurl.com/zme96wx
that we can operate in proxy environments.

cc @lucab @crawford @coresolve

[squat]

As written in #2460, all tests fail because /etc/profile.env does not exist, so systemd fails to start k8s-node-bootstrapper, so kubelet.env is never created, so kubelet fails to start. kubelet.service:

Jan 18 11:49:08 ip-10-0-4-128 systemd[1]: kubelet.service: Failed to load environment files: No such file or directory
Jan 18 11:49:08 ip-10-0-4-128 systemd[1]: kubelet.service: Failed to run 'start-pre' task: No such file or directory
Jan 18 11:49:08 ip-10-0-4-128 systemd[1]: Failed to start Kubelet via Hyperkube ACI.
Jan 18 11:49:08 ip-10-0-4-128 systemd[1]: kubelet.service: Unit entered failed state.
Jan 18 11:49:08 ip-10-0-4-128 systemd[1]: kubelet.service: Failed with result 'resources'.
Jan 18 11:49:18 ip-10-0-4-128 systemd[1]: kubelet.service: Service hold-off time over, scheduling restart.
Jan 18 11:49:18 ip-10-0-4-128 systemd[1]: Stopped Kubelet via Hyperkube ACI.

[squat]

ok to test

[coresolve]

Turns out this needs to be /etc/ssl/certs/ca-certificates.crt

The go binary can't read all the certs it needs the cert bundle specifically.
We need /etc/ssl/certs/ca-certificates.crt as opposed to /usr/share/certs/ca-certificates.crt as we need to be able to trust certificates that are added to the bundle at install time. The /usr/share/cert I think is immutable.

[squat]

This change was cherry-picked from your PR. Should I make that change for you?

[coresolve]

Need to change the cert path.

[squat]

ping @coresolve

[coresolve]

The change looks good. I think I am still trying to figure out where to get the proxy env vars from. I was using /etc/profile.env because of this guidance:
https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html#system-wide-environment-variables

With this doc floating around I think we need to agree on an approach.

[euank]

Would it be bettre to use --env HTTP_PROXY --env NO_PROXY (and any other proxy-related variables; those are the ones the go stdlib understands iirc)?

The profile.env file is meant for full shell parsing and for interactive user shells, so it's perfectly possible a user will, for valid reasons, have set it to include more complex statements than docker's --env-file may understand.

Minimizing the set of environment variables getting passed through is also good from a security perspective.

With the --env suggestion above, using a dropin for specifically this service or globally via /etc/systemd/system.conf.d/ should work, and it won't require touching anything in the default case since docker doesn't error if an --env value doesn't exist.

[coresolve]

the problem tho is that the docker container needs the env vars. I am fine with pointing at a diff file. In most cases I am blindly expecting the env vars in /etc/profile.env to apply cleanly here.

[coresolve]

I think this makes sense. Basically extend the k8s-node-bootstrapper.service with the proxy vars and feed them in with --env This is probably cleaner cause the --env-file doesn't have to exist.

[sym3tri]

This is planned to be superseded by forthcoming PRs.