📖 Add TLS Profile Compliance Design document#1027
Open
zhujian7 wants to merge 9 commits intostolostron:mainfrom
Open
📖 Add TLS Profile Compliance Design document#1027zhujian7 wants to merge 9 commits intostolostron:mainfrom
zhujian7 wants to merge 9 commits intostolostron:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: zhujian7 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
zhujian7
force-pushed
the
docs-tls-profile-compliance-design
branch
2 times, most recently
from
7dbdfb5 to
a4ac135
Compare
Contributor
Author
|
/cc @qiujian16 @elgnay |
zhujian7
force-pushed
the
docs-tls-profile-compliance-design
branch
2 times, most recently
from
df0de12 to
fc3fa5d
Compare
Add comprehensive design document for implementing TLS profile compliance across server foundation repositories (OCM hub/spoke components and Stolostron). This addresses ACM-26882 requirement for OpenShift 4.22 GA and Post-Quantum Cryptography (PQC) readiness. Key aspects: - Sidecar + ConfigMap pattern for dynamic TLS configuration - Upstream/downstream separation (OCM remains K8s-agnostic) - ConfigMap propagation strategies for hub and spoke scenarios - Implementation details for operators, agents, and addon components Related: ACM-26882 🤖 Assisted by Claude Code Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Improve the TLS Profile Compliance Design document with: - Add explanation of how sidecar+ConfigMap pattern resolves upstream challenge - Convert deployment relationships to table format for clarity - Consolidate Scenarios 1 & 2 (identical solutions) - Streamline implementation sections (remove verbose "How It Works") - Condense FAQ answers while preserving technical content - Reduce document length by 24% without losing information - Improve scannability with shorter paragraphs and bullet points Technical content remains unchanged; purely editorial improvements. 🤖 Assisted by Claude Code Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Update TOC to reflect actual document structure: - Swap "Solution Overview" and "Scenario Summary" order - Add missing sections: FAQ, Approval and Sign-off, References This matches the document reorganization where Solution Overview now comes before Scenario Summary for better logical flow. 🤖 Assisted by Claude Code Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Convert Solution column text to clickable links that jump to the detailed scenario sections. This improves navigation and makes it easier for readers to find the full implementation details for each scenario. - Scenarios 1 & 2 link to combined section - Scenarios 3-8 link to individual sections - Scenario 9 remains TBD (no link) 🤖 Assisted by Claude Code Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Update the TLS Profile Compliance Design to use the OpenShift centralized TLS configuration pattern (flag-based approach) for hub components and spoke agents (Scenarios 4 & 7). Key changes: - Scenarios 4 & 7 now use operator flag injection instead of ConfigMap watch pattern - Operators read ConfigMap and inject TLS values as command-line flags (--tls-min-version, --tls-cipher-suites) - Operators trigger component rollouts via deployment annotation (tls-config-hash) - Components parse flags on startup (simpler, no ConfigMap watch code needed) - Simplified Scenario 7: hosted vs default mode distinction removed - with flags, target namespace is just a parameter - Updated implementation details showing Pattern 1 (operators) vs Pattern 2 (components) - Added FAQ explaining flag approach benefits - Added reference to OpenShift centralized TLS config enhancement Benefits: ✅ Simpler components (no ConfigMap watch logic) ✅ Less RBAC (components don't need ConfigMap permissions) ✅ Follows OpenShift pattern for TLS configuration ✅ No ConfigMap copying needed for hosted mode ✅ Config visible in kubectl describe pod Scenarios 3 & 6 (operators) still use ConfigMap watch pattern since they're not managed by another controller. Signed-off-by: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Add a Future Enhancements section documenting a potential
multi-level TLS configuration hierarchy for klusterlet-operator.
This addresses feedback from the OpenShift TLS team about
supporting hub-driven TLS policy enforcement in advanced
deployments.
Changes:
- Added Future Enhancements section before Approval section
- Documented three-tier configuration hierarchy:
Priority 1: Hub-driven config (highest)
Priority 2: Local APIServer CR (hosting cluster)
Priority 3: Go defaults (TLS 1.2 fallback)
- Outlined two implementation options:
• Option B (Preferred): Hub creates ConfigMap that
klusterlet-operator reads
• Option C (Alternative): Add TLS config to Klusterlet CR spec
- Documented benefits and backward compatibility
- Current decision: Defer until concrete requirement exists
Context:
In hosted mode, klusterlet-operator runs on a hosting cluster
but manages a separate managed cluster. Currently it uses the
hosting cluster's APIServer TLS profile. This enhancement would
allow the hub to override this with stricter policies if needed.
The current design (local APIServer via sidecar) remains
unchanged. This is documented as a future enhancement only.
Signed-off-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: zhujian <jiazhu@redhat.com>
Added a concise pattern summary section that categorizes all 8 scenarios into 4 fundamental patterns for easier understanding: - Case 1: ConfigMap Creation + Self-Managed Components (Scenarios 3, 5, 6) - Case 2: Operators Inject Flags into Components (Scenarios 3→4, 6→7) - Case 3: Components Receive Flags (Scenarios 4, 7) - Case 4: Addon Agents with ConfigMap Copy (Scenario 8) This provides a high-level overview before diving into detailed scenarios, making it easier for teams to understand the overall architecture and their specific implementation requirements. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> Signed-off-by: zhujian <jiazhu@redhat.com>
zhujian7
force-pushed
the
docs-tls-profile-compliance-design
branch
2 times, most recently
from
74041fe to
4d7f6b1
Compare
Add visual architecture diagram (tls-profile.png) showing the complete TLS profile compliance flow across hub and managed clusters. The diagram illustrates: - Sidecar injection pattern for cluster-manager and klusterlet-operator - ConfigMap creation from OCP APIServer TLS Config - Flag injection to operators (--tls-min-version, --tls-cipher-suites) - Addon agents reading ConfigMap on managed clusters - Component relationships and namespaces Placed in Simplified Pattern Summary section to provide visual overview before detailed pattern descriptions. 🤖 Generated with Claude Code Signed-off-by: zhujian <jiazhu@redhat.com>
zhujian7
force-pushed
the
docs-tls-profile-compliance-design
branch
from
4d7f6b1 to
cdebcab
Compare
Add note that the tls-profile-sync sidecar is responsible for converting OpenShift OpenSSL-style cipher names to IANA format expected by upstream OCM, keeping upstream code format-agnostic. Signed-off-by: Jia Zhu <jiazhu@redhat.com> Signed-off-by: zhujian <jiazhu@redhat.com>
Closed
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds a comprehensive design document for implementing TLS profile compliance across server foundation repositories (OCM hub/spoke components and Stolostron components).
Related Issues
Test Plan
🤖 Generated with Claude Code