-
Notifications
You must be signed in to change notification settings - Fork 242
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
Root CA bundle #1316
Root CA bundle #1316
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kron4eg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest |
1 similar comment
/retest |
39b2ce2
to
7981d15
Compare
// CABundle PEM encoded global CA | ||
CABundle string `json:"caBundle,omitempty"` |
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'd say that this should be a path to the bundle on local FS instead of the bundle itself. The bundle can be huge (the Mozilla one is 3k+ lines).
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.
While yes, the original public CA bundle is long, this field should only be used in case when you have your very own custom CA bundle, which most likely will not be that long.
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 still prefer if we would reference a file instead of embedding it in the KubeOne config manifest. We can't know for sure how long is the CA bundle. Theoretically, it can range from several dozens of lines to several thousand. From the user experience side, I believe referencing the file is better because the manifest is smaller and easier to maintain.
Additionally, we use this pattern in other places as well, such as:
- addons
- PodNodeSelector and StaticAuditLog features
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.
Then let's build on top of this PR as it's already quite big. My proposal would be to retrofit the "special content" linking.
I.e. let's have file:///path/to/file
in .CABundle
and in case if it starts from file://
that will be interpreted as reference to the file, instead of actual content.
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.
This sounds like a good plan. Can you create a follow-up issue for this?
3f5280a
to
cd08287
Compare
/retest |
6546504
to
52b424b
Compare
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.
Is there a way to test this feature in an automated way, i.e. with the E2E tests? If yes, we should do that in a follow-up (please create a ticket in that case).
// CABundle PEM encoded global CA | ||
CABundle string `json:"caBundle,omitempty"` |
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 still prefer if we would reference a file instead of embedding it in the KubeOne config manifest. We can't know for sure how long is the CA bundle. Theoretically, it can range from several dozens of lines to several thousand. From the user experience side, I believe referencing the file is better because the manifest is smaller and easier to maintain.
Additionally, we use this pattern in other places as well, such as:
- addons
- PodNodeSelector and StaticAuditLog features
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
…lates Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
Signed-off-by: Artiom Diomin <[email protected]>
LGTM label has been added. Git tree hash: 35429b94a7f4d49f3c51eb90eab28f7d25622330
|
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #1298
Special notes for your reviewer:
Does this PR introduce a user-facing change?: