docs: add proposal of Karmada Self-Signed Certificate Content Standar… #6189
Conversation
…dization Signed-off-by: tiansuo114 <zhaoyi_114@outlook.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #6189 +/- ##
==========================================
- Coverage 47.97% 47.89% -0.08%
==========================================
Files 674 676 +2
Lines 55841 55978 +137
==========================================
+ Hits 26788 26810 +22
- Misses 27305 27418 +113
- Partials 1748 1750 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Preliminary Design Document DiscussionThis document is an initial design draft. However, there are some unresolved questions regarding the overall system design that I have raised in the document. For clarity, I will describe the issues again here. 1. Secret Generation During Cluster Deployment
2. Generating Individual Certificate Files for Each ClientI have encountered some design issues when considering generating independent, usable certificate files for each client. I currently have two approaches: Option 1:
Option 2:
3. Using a Consistent Certificate Across Different Servers for the Same Client
|
| - **8 Server Components:** | ||
| 1. karmada-apiserver | ||
| 2. karmada-scheduler | ||
| 3. karmada-controller-manager |
There was a problem hiding this comment.
What is karmada-controller-manager used for as a server?
There was a problem hiding this comment.
In my understanding, the use of karmada-controller-manager as a server component is roughly: Karmada-controller-manager is Karmada The core control plane component of the multi-cluster orchestration system manages some controllers (such as execution,binding, etc.) to perform cluster resource orchestration and service governance functions
If there is any mistake in my answer or understanding of the question, please let me know and I will correct it in time😭
There was a problem hiding this comment.
When we determine whether a component assumes the role of a server, we can think from the perspectives of who the clients accessing it are and what its functions are as a server. You mentioned "metrics" in the following comment. When acting as the provider of metrics, the controller-manager serves as the server.
There was a problem hiding this comment.
I am very sorry that my understanding here is not correct. After I confirmed again,karmada-controller-manager does not seem to have similar functions to server-side components
| 4. karmada-cluster-controller | ||
| 5. karmada-policy-controller | ||
| 6. karmada-work-controller | ||
| 7. karmada-binding-controller | ||
| 8. karmada-status-controller | ||
| 9. karmada-federated-resource-controller | ||
| 10. karmada-propagation-controller | ||
| 11. karmada-execution-controller |
There was a problem hiding this comment.
Do the different Controllers inside the karmada-controller-manager need to be handled separately?
There was a problem hiding this comment.
I think we should generate a client certificate for controller-manager as a whole to communicate with karmada-apiserver, and a server certificate for controller-manager's API endpoints (health check and metrics).
There was a problem hiding this comment.
I think we should generate a client certificate for controller-manager as a whole to communicate with karmada-apiserver
Agree, these Controllers should be regarded as a whole, that is, the karmada-controller-manager. Therefore, for the sake of easy understanding, you can simply write "karmada-controller-manager".
and a server certificate for controller-manager's API endpoints (health check and metrics)
This is a good concern. Although currently we don't have the configuration for certificate verification regarding health check and metrics (please correct me if I'm wrong).
There was a problem hiding this comment.
Yes, after confirmation, my understanding is wrong. karmada-control-manager does not seem to have similar functions as a server-side component. Therefore, I think it is not necessary to generate a server-side certificate for Karmada-Control-Manager, but only a unified client authentication certificate for the client components under its management
|
|
||
| - Generate Independent Secrets: | ||
| - Modify the certificate upload logic in `operator/pkg/tasks/init/upload.go` to replace the shared certificate handling with individual Secret creation for each component. | ||
| - Add new functions to create these independent Secrets and enforce new RBAC rules to restrict each component’s access to its own certificate. |
There was a problem hiding this comment.
enforce new RBAC rules to restrict each component’s access to its own certificate.
Does the component need the RBAC permission for the certificate, considering that the secret is mounted onto it as a volume?
There was a problem hiding this comment.
Your observation is correct. There is some misunderstanding here, when the certificate Secret is mounted to the component as a volume, the component itself does not need additional RBAC permissions to access the certificate files.
This is because:
-
The mounting of Secret is done by kubelet: kubelet is responsible for mounting the contents of Secret as a file inside the container.
-
Applications in containers only need file system permissions: Applications in containers only need read permissions to the file system, not access to the Kubernetes API.
-
Only the component responsible for managing secrets requires RBAC permissions: For example, karmada-operator needs to have the appropriate RBAC permissions to create and manage these secrets.
Therefore, for the management of certificate Secret, we should follow the following policies:
-
Keep the management rights of karmada-operator on all certificate secrets, and ensure that Karmada-Operator can create, update, and delete related certificates.
-
Do not add RBAC permission for other components (such as controller-manager) to access certificate Secret to avoid unnecessary permission exposure.
-
Ensure that volume mounting is configured correctly: Each component should be able to access only the certificates it needs, preventing other components from accessing unrelated secrets.
If my understanding is not correct, I hope you can correct it
|
@tiansuo114 Thank you for your proposal as it is valuable for the security of the project. In fact, the changes in the certificate configuration will ultimately be reflected in the fields of the certificate. And the proposal you put forward in your proposal mainly affects the Certificate:
Data:
Signature Algorithm: sha384WithRSAEncryption
Issuer: CN = karmada
Subject: O = system:masters, CN = system:admin
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:*.karmada-system.svc.cluster.local, DNS:*.karmada-system.svc, DNS:localhost, IP Address:127.0.0.1, IP
|
Thank you for the detailed description. The certificate updates you mentioned primarily affect the Subject and Subject Alternative Name (SAN) fields. Below are the key differences between the certificates before and after the changes: Before Changes (Current Implementation)Server Certificate (
|
Signed-off-by: tiansuo114 <zhaoyi_114@outlook.com>
Signed-off-by: tiansuo114 <zhaoyi_114@outlook.com>
|
The content of the document has been updated according to the results of the meeting. How does it look now? |
| **Expected Outcomes:** | ||
| - Issue distinct certificates for 8 server components and store them in corresponding Secrets | ||
| - Issue distinct certificates for 11 client components and store them in appropriate Secrets/ConfigMaps | ||
|
|
||
| ### Non-Goals | ||
|
|
There was a problem hiding this comment.
We can clarify that this task aims to design a universal certificate segregation framework for Karmada. Based on this framework, the certificate issuance and usage of the hack installation method will be reformed. Other installation methods, such as helm, operator, and karmadactl init, are not covered for now.
There was a problem hiding this comment.
Ok, I'll sync this change to the document right away
In addition, do you have any comments or suggestions about the revision of the article? I want to know if my current modification ideas are correct. If so, I want to start by trying to modify the bash files in the hack path and the yaml files in the artifacts/deploy path used during deployment
…ocument Signed-off-by: tiansuo114 <zhaoyi_114@outlook.com>
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Design documentation for supporting karmada's new self-signed certificate system
Which issue(s) this PR fixes:
Part of 6091
Special notes for your reviewer:
@XiShanYongYe-Chang
@chaosi-zju
Does this PR introduce a user-facing change?: