-
Notifications
You must be signed in to change notification settings - Fork 47
Add AutoProvider certificate manager
#227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ArkaSaha30 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
f819caf to
82651bc
Compare
AutoProvider interface functionsAutoProvider interface functions
|
@abdurrehman107 @ballista01 @ivanvc @hakman PTAL. Reviewing this PR is also an opportunity to get familiar with the certificate design & implementation. Reference: https://docs.google.com/document/d/1k8os77Hqxe36nUaZ31YqBGBuXcgdozVPppJYOfwUDFA/edit?tab=t.0 |
|
cc @frederiko |
276d55e to
9886706
Compare
AutoProvider interface functionsAutoProvider certificate manager
| return nil, fmt.Errorf("failed to get certificate: %w", err) | ||
| } | ||
|
|
||
| return &interfaces.Config{}, nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should get the info from the certificate included in the secret.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @ahrtr , I explored getting the original config from the secret itself but it will be a complicated one since we are manipulating the config and passing it to transport.SelfCert() which in turn creats the certificate.
Another workaround is to retrieve the certificateConfig from the etcdCluster object via the certificateSecret.ownerRef.Name, but it will cause a circular dependency
What can be the suggested solution here?
cc @ivanvc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but it will be a complicated one
Where is the complication? I don't see a PoC so far, nor a reasonable explanation.
The easiest solution is to just save the config passed to EnsureCertificateSecret, and return it in GetCertificateConfig. The problem is that it isn't the final real configuration that we used to create the certificate.
ivanvc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the pull request, Arka. I left some observations, comments, and suggestions.
| if autoConfig.AltNames.DNSNames != nil { | ||
| getAltNames = certInterface.AltNames{ | ||
| DNSNames: autoConfig.AltNames.DNSNames, | ||
| IPs: make([]net.IP, len(autoConfig.AltNames.DNSNames)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of this? Is the plan to fill it later? I can't find it in the current code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we are preparing the certificate config here from the user-defined config for etcd-operator. This config will be passed to the createCertificate function where based on the provider EnsureCertificateSecretwith the above mentioned config parameter will be passed to create the certificateSecret
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But, this is not being used anywhere. I can see how it is filled for CertManager:
| ipAddresses = make([]net.IP, len(cmCertificate.Spec.IPAddresses)) |
And used:
| IPAddresses: strings.Fields(strings.Trim(fmt.Sprint(cfg.AltNames.IPs), "[]")), |
Unless I'm not following through, as this slice is always empty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using it here for creating the self-signed certificate: https://github.com/ArkaSaha30/etcd-operator/blob/auto-cert-provider/pkg/certificate/auto/provider.go#L224-L232
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But IPs are not being used, should it come as a part of the hosts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the DNS names, not the IP addresses. This slice is kept empty with a capacity of len(autoConfig.AltNames.DNSNames). @ahrtr, do we need the IPs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should populate the IPs with whatever the IPs passed by users (otherwise we should remove IPAddress from the user-facing config), although usually in practice IPAddresses aren't used, because POD IPs are dynamic.
Please update the createCMCertificateConfig to populate the IPs with user provided values as well. It can be resolved in a separate PR.
We can think about to refactor the user interface or implementation in future when we get more feedback from real users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should populate the IPs with whatever the IPs passed by users (otherwise we should remove IPAddress from the user-facing config), although usually in practice IPAddresses aren't used, because POD IPs are dynamic.
I think we should delete the IPAddressess property because, as you said, this will get invalidated with pod rotations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should delete the
IPAddressessproperty because, as you said, this will get invalidated with pod rotations.
I suggest that we follow comment to proceed for now. For any user facing API change, we should get more feedback. Let's discuss it separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest that we follow comment to proceed for now
I mean #227 (comment)
9886706 to
f1f6535
Compare
This commit will add the initial scaffolding for AutoProvider. Signed-off-by: ArkaSaha30 <[email protected]>
c1da674 to
9d90c9e
Compare
Signed-off-by: ArkaSaha30 <[email protected]>
Signed-off-by: ArkaSaha30 <[email protected]>
Signed-off-by: ArkaSaha30 <[email protected]>
9d90c9e to
e2c11fd
Compare
|
/test pull-etcd-operator-test-e2e |
|
@ArkaSaha30, where do we stand in this pull request? Is this ready for another review? |
| } | ||
| } | ||
|
|
||
| tlsInfo, selfCertErr := transport.SelfCert(zap.NewNop(), tmpDir, hosts, uint(validity/DefaultValidity)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you decide to use the fake host ports as we discussed during the meeting of 25 Nov, due to the bug in SelfCert not working for hosts without port, then remember to use net.JoinHostPort for adding a port. the function is IPv4/6 compatible.
This PR will add
AutoProvidercertificate manager as a part of generating default self-signed certificates: