-
Notifications
You must be signed in to change notification settings - Fork 589
add signer:rootcert map into mesh config #2090
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
Conversation
|
/test release-notes_api |
|
I think you have to run "make proto-commit" to update proto.lock with new changes. |
|
@myidpt @costinm @howardjohn @shankgan Please take a look at this PR to see whether it is on the right direction. Thanks! |
|
Storing public keys in secrets seems unnecessary and complex. We already
have a dozen ways to handle public keys and CAs - can we extend one of the
existing ones ?
…On Sat, Sep 18, 2021, 07:54 John Howard ***@***.***> wrote:
Assigned #2090 <#2090> to @costinm
<https://github.com/costinm>.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#2090 (comment)>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2WYNXJTMNC6W6546KDUCSR2JANCNFSM5DTQ3L2Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Also, why in meshconfig ? We have other ca settings in ProxyConfig - why
would this be a global setting instead of per namespace/workload ?
…On Fri, Sep 17, 2021, 11:06 shankgan ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In mesh/v1alpha1/config.proto
<#2090 (comment)>:
> @@ -877,8 +877,13 @@ message MeshConfig {
// configured globally via this field.
istio.networking.v1alpha3.HTTPRetry default_http_retry_policy = 62;
+ // Map of root certs for kubernetes CSR signers when Istiod is acting as RA(registration authority)
+ // Key is the signer name and value is the secretName which stores the root certs for the signer
+ // signer1: signer-root-cert.ns1
+ map<string, string> signer_root_certificate = 63;
nit: does this need to be a secret, as opposed to a configmap? Don't have
any objection to using secret, just curious
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2090 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAUR2WQERKIKR7E35FJRILUCN7SRANCNFSM5DTQ3L2Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
@costinm Thanks for the review! The reason to add this into meshConfig instead of ProxyConfig is because
I also went through the related fileds in meshConfig and have not found a good match for this task: sepcify root certs for different signers:
this can not be used as it lack of places to specify signer name.
|
|
If we are going to move forward with #1923 we may want consistency there. @mathetake @lizan is there still interest in that API? If so, it may make sense to add two fields there: "trust_domains" for the use case in 1923 and "signers" for the use case in 1923. |
|
oh yeah we are still interested in 1923 so I would really appreciate it if we could leverage the API introduced here (trust_domains field). |
5813226 to
af5b97a
Compare
|
@howardjohn @shankgan PTAL to see the latest change which is reusing the certificate_data filed. @mathetake PTAL to see whether the adding for trust_domains is approriate or you want to take care of it in a separate PR. Thanks! |
mathetake
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 LGTM from me! (though I'm not sure if I can finish the multiple trust domains impl part for 1.12 as I am going into vacation for two weeks beginning the next week).
mesh/v1alpha1/config.proto
Outdated
| } | ||
| // Optional. Specify the kubernetes signers to which this certificate data belongs to | ||
| // when Istiod is acting as RA(registration authority) | ||
| // If set, they are used for these signers. Otherwise, this root CA is used for default signer. |
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 set, they are used for these signers. Otherwise, this root CA is used for default signer. | |
| // If set, they are used for these signers. Otherwise, this root CA is used for all signers. |
This enables a few things...:
- Backwards compatibility preserved
- You can opt into allowing 2 different signers to trust each other. This is critical for a migration between CAs
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.
fixed
mesh/v1alpha1/config.proto
Outdated
| // The certificate is retrieved from the endpoint. | ||
| string spiffe_bundle_url = 2; | ||
| } | ||
| // Optional. Specify the kubernetes signers to which this certificate data belongs to |
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.
nit: "//Optional. Specify the kubernetes signers (External CA) that use this CA certificate" - think this sounds better
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.
fixed
mesh/v1alpha1/config.proto
Outdated
| // If set, they are used for these signers. Otherwise, this root CA is used for default signer. | ||
| repeated string cert_signers = 3; | ||
|
|
||
| // Optional. Specify the list of trust domains to which this certificate data belongs. |
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.
nit: could we replace the word certificate with trustAnchor in all the comments? This can be done in a later PR if needed.This entire field is used for CA certificates, that are used as trustAnchors within the mesh. The use of the word "certificate" is ambiguous IMO.
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.
fixed
howardjohn
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.
A few small comments to address but overall lgtm
ff4ad5c to
306fa26
Compare
Thanks! I addressed the comments and removed the on-hold label to get it in. Glad to address new comments in following up PR if needed. |
If istio acting as RA, user can specify signers for the CSR, We need a way to let user specify root cert for each of the signers. Detailed discussion can be found in: istio/istio#34486
This also opens doors for us to define signer to replace
kubernetes.io/legacy-unknownfor istiod certs, a related proposal is hereAnother related proposal is here: https://docs.google.com/document/d/1rxTSLuepcE_OJHj4C23RMJcgyIZzlBI-GqO8Y37SPko/edit#heading=h.5l3l3tiit0zd , see
Distribution of root of trust for signerssection