Manage external cert#233
Conversation
| // If set to false, you must provide your own certificates via Secret. | ||
| // Default: true | ||
| // +optional | ||
| AutoProvision *bool `json:"autoProvision,omitempty"` |
There was a problem hiding this comment.
Hmm... maybe just default to auto provision in the code if SecretName isn't set, then the user doesn't have to remember to disable and we don't need to track this variable.
There was a problem hiding this comment.
You're right. It seems that we can detect secretName or certFilesPath user want to mount to decide whether to auto provision
gflarity
left a comment
There was a problem hiding this comment.
As discussed, let's simplify the logic by enabling automatic certs when the secretName isn't provided.
faba093 to
fc4f28a
Compare
|
a0bb706 to
53ca78c
Compare
gflarity
left a comment
There was a problem hiding this comment.
Thanks, left an example that I implemented a while ago (running in production for some time now). The only difference is we need to enable auto provision. Otherwise you can just follow this.
0cc29d4 to
4c83e1b
Compare
|
Sorry for the delay, planning to review this today. |
There was a problem hiding this comment.
Thanks @kangclzjc, gave it a quick review today. Looks good, I'll do a slower review tomorrow morning first thing. In the mean time:
One thing we'll need is a simple E2E test to verifying everything works using cert manager. Please take a look at the current E2E tests, all it really needs to do is install cert manager, then update the helm values to use it. If you start a simple grove deployment successfully, it means the webhooks are still working with this change.
There is code in the cluster setup utilities for installing a helm chart (cert manager). You should be able to reuse some of that logic to install cert manager for this specific test. Please let me know if you have any questions.
Thanks @gflarity , let me check the E2E test first. And then do a simple E2E test to verifying everything works using cert manager. |
gflarity
left a comment
There was a problem hiding this comment.
Just a couple small things, otherwise looks good. Just need the E2E test(s).
dabcda6 to
46d8d99
Compare
gflarity
left a comment
There was a problem hiding this comment.
Left some feedback on the E2E test.
68612bc to
766953a
Compare
|
Just circling back on this @kangclz so we can get it merged. What's the current status? Please resolve any comments you believe have now been addressed. Also, looks like the E2E tests are failing. Please try rebasing from main to see if that helps with the tests. |
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: Bashorun97 <bashorun.emma@gmail.com>
Signed-off-by: Bashorun97 <bashorun.emma@gmail.com>
Signed-off-by: Bashorun97 <bashorun.emma@gmail.com>
Signed-off-by: Emmanuel Bashorun <bashorun.emma@gmail.com>
Signed-off-by: Emmanuel Bashorun <bashorun.emma@gmail.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
Signed-off-by: kangclzjc <kangz@nvidia.com>
|
Closing this PR in favour of #344 |
What type of PR is this?
Currently we do the certificate generation ourselves. If they already have certificate in their system, we should manage external existing certificate by mounting them
What this PR does / why we need it:
We add support for allowing user to use external cert
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a API change?
Additional documentation e.g., enhancement proposals, usage docs, etc.: