TLS init

[thisisnotashwin]

Changes proposed in this PR:

• Create sub command tls-init that manages creating server tls certificates.

The responsibility of the subcommand is as follows:

• If CA cert/private key as provided as file paths, create a Server TLS cert/key pair and save that as a TLS secret in kubernetes.
• If a CA isn't provided, create a CA and save the CA certificate and private key as separate Kubernetes secrets. This CA/key will be used in all successive Server certificate/key generations.

How I've tested this PR:

• Updated helm to use the image ashwinvenkatesh/consul-k8s:tls-init and also updated the TLS-init job to use the consul-k8s binary with the tls-init subcommand. I tested initial TLS cert generation, updating the DNS sans and performing a helm upgrade. This issued new certificate that the consul servers would start using after they were restarted. ran openssl s_client -connect localhost:8501 from within the server pods to validate that they did infact use the new certificated that had updated DNS sans
• Units tests

How I expect reviewers to test this PR:

• Unit tests
• Code review

I will add instructions for how to test the end to end flow on a corresponding helm-PR

Checklist:

• Tests added
• CHANGELOG entry added (HashiCorp engineers only, community PRs should not add a changelog entry)

Closes hashicorp/consul-helm#512, Makes hashicorp/consul-helm#719 unnecessary

[ishustava]

Wow! Awesome work, Ashwin! I love that it's now a command and how thorough you were with tests. I had some comments about the code and a bunch of edits. I'm still reviewing and would also like to try it out, but I thought I'll leave the comments I have so far.

Thanks for doing this refactor!

[ndhanushkodi]

This is awesome work!! Do you think it would be worth adding a test to make sure the CA isn't recreated if it exists?

[thisisnotashwin]

Do you think it would be worth adding a test to make sure the CA isn't recreated if it exists?

@ndhanushkodi I considered this, but I was hoping the tests that use the CA from a secret or from a filepath have assertions that validate that the created server certificates were created using the existing CA, which would fail in case a new CA was created. I could add a test that asserts that explicitly though, but I felt like it was covered by the existing tests.

I was wrong. It does not verify that it used the existing CA cert. Will add that test. Good catch.

Follow up: Added

[ishustava]

Looks great, Ashwin! I've left some edits and comments, but they are mostly "cosmetical", non-blocking. I've tried it out too, and it works like magic 🧙‍♂️ !