[Proposal] [Security Hardening] Add support for specifying pod security context for components provisioned by the operator

[jabellard]

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Part of #7539
Special notes for your reviewer:

Does this PR introduce a user-facing change?:

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a proposal to enhance the security posture of components managed by the Karmada operator. By allowing users to specify Pod Security Contexts directly within the Karmada CR, the change facilitates compliance with strict organizational security policies and Kubernetes Pod Security Admission standards, ensuring that control plane components can run in restricted environments without manual intervention.

Highlights

• Proposal Documentation: Added a new design proposal document outlining the implementation plan for supporting Pod Security Context in the Karmada operator.
• Security Compliance: The proposal enables configuration of pod-level security contexts to meet Kubernetes Pod Security Standards (PSS) and CIS benchmark requirements.
• API and Patcher Design: Defined the addition of a SecurityContext field to the CommonSettings struct and outlined the required builder method for the operator's patcher logic.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a proposal documenting how the Karmada operator should support configuring pod-level security context for control-plane components via the Karmada CRD.

Changes:

• Proposes adding securityContext (pod-level) to the operator API (CommonSettings)
• Proposes extending the patcher to apply the configured PodSecurityContext to Deployments/StatefulSets
• Defines motivation, user stories, and an initial test plan for the feature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[gemini-code-assist]

Code Review

This proposal introduces support for configuring Pod Security Contexts for Karmada control plane components managed by the operator. It adds a new field to the CommonSettings struct and updates the patcher logic to apply these settings to Deployments and StatefulSets. The reviewer suggests renaming the SecurityContext field and its associated builder methods to PodSecurityContext to explicitly distinguish them from container-level settings and maintain consistency with the Kubernetes API. Additionally, the documentation should be clarified to reflect that the field specifically targets pod-level attributes.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 42.07%. Comparing base (03b39dd) to head (e82878a).
⚠️ Report is 62 commits behind head on master.
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #7540      +/-   ##
==========================================
+ Coverage   41.92%   42.07%   +0.14%     
==========================================
  Files         879      879              
  Lines       54328    54610     +282     
==========================================
+ Hits        22776    22975     +199     
- Misses      29829    29913      +84     
+ Partials     1723     1722       -1     

Flag	Coverage Δ
unittests	42.07% <ø> (+0.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[RainbowMango]

/assign

Will look at it next week.

[zhzhuang-zju]

Thanks, Joe. This is a useful configuration to harden Karmada security.

Regarding the feature, I have two questions:

• Do we need to set a default security context for Karmada components to comply with default security policies?
• Do Karmada components support configuring the security context? In my previous tests, setting runAsUser and runAsNonRoot caused functional abnormalities (not sure about the current status). Can we safely expose this API for users to use?

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from rainbowmango. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jabellard]

Thanks, Joe. This is a useful configuration to harden Karmada security.

Regarding the feature, I have two questions:

• Do we need to set a default security context for Karmada components to comply with default security policies?
• Do Karmada components support configuring the security context? In my previous tests, setting runAsUser and runAsNonRoot caused functional abnormalities (not sure about the current status). Can we safely expose this API for users to use?

Thanks for letting me know about this. It's important to acknowledge that not all combinations of the config will work. I think that's OK as long as we document that. I just pushed some changes to address that. Please take a look.

[RainbowMango]

Can you elaborate on the issues here? @zhzhuang-zju , like which components with what configuration would cause issues? If it is true, shall we introduce some sort of validation?

[zhzhuang-zju]

I'm not entirely sure at the moment. I just remember that some components behaved abnormally after we configured runAsUser and runAsNonRoot. We need to run additional tests if we want more details.