Option for using cert-manager for TLS / clarify docs

[davidkarlsen]

https://github.com/anchore/anchore-charts/blob/master/stable/anchore-admission-controller/templates/init-ca/init-ca-script.yaml seems to have some manual jobs to be applied for generating some TLS certificates, and it will require internet access as it's based on some downloads, apt etc. This is a bit of a hassle /tricky in air-gapped environments where you might need to go through a proxy etc.

Depending on what the requirements to this certificate (what is it used for / why is it - could maybe be more smooth by using cert-manager for certificate issuing and rotation? Maybe it's even better to handle this outside of the chart and simply refer to an existing secret (which could be generated by any means - including cert-manager).

Background in slack: https://anchorecommunity.slack.com/archives/C4PJFNEEM/p1575834841399400

[zhill]

I'm all for simplifying this. I tried at one point using the CA abilities of Sprig but wasn't quite able to get it working on the apiserver side where the CA seemed to be not configured quite correctly. I think the requirements are: autogen one if not provided, and enable user to easily add their own if desired. Beyond that, I'm all for best-practices here.

[FOTempel]

Soo, what's the progress on this? Requiring internet access for a single use init container stopped me dead in my tracks with deploying this chart. I understand that the certificates are needed to make the API server communicate with the admissioncontroller. Understandable. But it would be great if I could just inject my own certificates as a secret or something without the need for that very large init container and complex scripting that goes around it. I'd wager most organizations security conscious enough to even consider an admission controller already have their own ways and methods to deal with certificates. A simple switch in the chart to disable the init container as a quick "fix" would already go a long way, I can manage my own required k8s resources if needed (some documentation on that would also be appeciated but I can reverse engineer it if needed).

[davidkarlsen]

I have a few PRs in (and one merged already) to clean things up. Also CI is added so it is faster and safer to move around. Follow the PRs which are active.

[zhill]

Yes, this is an in-progress work. Understand the need and will ensure it gets added. Thanks for a bunch of great work by @davidkarlsen on this!

[zhill]

Looking into it further, I'm not sure we even need the APIService component at all that can greatly simplify the chart. I think as long as a valid caBundle is present in the service and in the webhook client config, that the webhook can be called cleanly. I'm investigating this and any feedback appreciated.

[FOTempel]

Looking into it further, I'm not sure we even need the APIService component at all that can greatly simplify the chart. I think as long as a valid caBundle is present in the service and in the webhook client config, that the webhook can be called cleanly. I'm investigating this and any feedback appreciated.

I think simplifying the chart is a good idea. I'd be happy to test anything you put out. I'm really interested in giving the admissioncontroller a go but I haven't found the time yet to get something working with a modified chart or even setting it up by hand.

[davidkarlsen]

Any findings so far? Also some comments in this PR: #13

[zhill]

I started digging in but got diverted on some other product work, so I've not been able to really test bigger modifications to the flow. I'll update here as soon as I'm able to get some results to report.

[zhill]

cc @markyjackson-taulia