-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
-
False
-
Not Selected
This initiative drives a comprehensive overhaul of the policy-collection repository https://github.com/open-cluster-management-io/policy-collection to transition from a static library of examples to a dynamic Compliance-as-Code engine. We are simplifying the user journey from "requirement" to "remediation" by pruning legacy technical debt and showcasing the use of the Policy Generator.
The Strategic Vision: To bridge the gap between regulatory standards (NIST 800-53, BSI IT-Grundschutz) and technical implementation. Users should be able to input a compliance profile and automatically receive the necessary ACM, Gatekeeper, VAP or to some smaller extend Kyverno policies.
🎯 Goals & Strategic Fit
- Repository Pruning: Purge appsub and placementrule in favor of the modern Placement API and ArgoCD/GitOps patterns.
- Modernized Delivery: Establish the Policy Generator as the standard for content creation to reduce manual YAML maintenance.
- Compliance Acceleration: Provide pre-mapped profiles (e.g., Nist, BSI IT-) to shift ACM's perception from a "toolbox" to a "compliance solution."
- High-Trust Standards: Deliver production-ready, functional examples that meet the expectations of enterprise customers and the open-source community.
🛠️ Use Cases
- The "Profile-to-Policy" Journey: A platform engineer selects a Compliance IT-Grundschutz profile. The Policy Generator consumes raw Kubernetes manifests and wraps them into ACM Policies, automating weeks of manual mapping.
- Automated Validation: CI suites use policy-generator-cli to validate that new contributions are correctly transformed and compliant with the latest schemas.
- Unified Governance: A single repository structure that demonstrates how ACM (Control Plane) manages Gatekeeper or Kyverno (Admission Control) in a unified workflow.
- How does it fit with AutoShift, ValidatedPattern for MultiCloudGitops
📋 Requirements
| Requirement | Description | MVP? |
| Legacy Pruning | Identify and remove all appsub and placementrule instances. | ✅ Yes |
| Content Audit | Delete outdated, non-functional, or non-recommended policy examples. | ✅ Yes |
| Policy Generator Adoption | All new content must be authored via PolicyGenerator manifests. | ✅ Yes |
| CI/CD Automation | Implement automated testing to ensure Generator manifests produce valid output. | ✅ Yes |
| BSI/NIST Alignment | Explicitly map folders to BSI (SYS.1.6/APP.4.4) and NIST standards. | ❌ No |
| AI Integration Research | Explore LLMs for mapping text-based docs to Generator YAML. | ❌ No |
⚖️ Critical Questions & Strategic Resolution
Migration Strategy
Approach: The "Seed and Lead" Strategy.
The core team will convert the top 20% of high-traffic "Manual" policies to the Generator format immediately. This provides a reference architecture for the community. Remaining low-traffic policies will be moved to a /deprecated folder.
Unified Governance Representation
Approach: The "Requirement-First" Directory Structure.
Folders will be organized by Compliance Goal rather than tool.
- policy-collection/stable/compliance/nist-800-53/ac-3-access-enforcement/
- policy-generator.yaml (The orchestrator)
- source-manifests/ (Contains Gatekeeper constraints, Kyverno rules, or ACM configurations)
👥 Customer & Contributor Impact
- From Consulting to Product: Automation lowers the barrier to entry, moving compliance mapping from a manual service to a product feature.
- Contributor Guidance: The CONTRIBUTING.md will be rewritten to prioritize the directory structure required by the Policy Generator.
Would you like me to draft a sample policy-generator.yaml that demonstrates the hand-off between ACM and Kyverno specifically, or should we move on to the updated CONTRIBUTING.md?
