[Security] Container Security Hardening for Quay and Mirror Registry

Overview

Implement security hardening for Red Hat Quay and OpenShift Mirror Registry container images by minimizing Linux capabilities to a least-privilege set and publishing a hardened seccomp profile for standalone deployments. These changes reduce attack surface and align with enterprise security best practices.

Context

Standalone deployments of Quay and Mirror Registry (via podman) lack the automatic seccomp hardening that OpenShift 4.11+ provides via RuntimeDefault. Additionally, the container images run with default Linux capabilities (not explicitly restricted), which does not follow the principle of least privilege.

This epic focuses on capability minimization and seccomp hardening. Read-only root filesystem support is tracked separately in PROJQUAY-8703 due to its complexity and the significant refactoring required for certificate installation and configuration generation.

Reference: PROJQUAY-9605

Scope

In Scope

• Audit and document minimal required Linux capabilities for Quay containers
• Implement capability DROP ALL with minimal required ADD set
• Create and publish hardened seccomp profile for standalone (podman) deployments
• Validate all Quay modes function correctly with restricted capabilities
• Documentation for security configurations and seccomp profile usage

Out of Scope

• readOnlyRootFilesystem support (tracked in PROJQUAY-8703)
• Changes to PostgreSQL or Redis container security (separate component ownership)
• Clair container hardening (tracked separately)
• Network policies or other Kubernetes security features
• Runtime security scanning integration

Child Stories

1. Capability Audit and Documentation: Audit all Quay container operations to identify the minimal required Linux capabilities. Document capability requirements for each component (registry, config, repomirror, workers). Test with DROP ALL to identify failures.
2. Implement Capability Minimization: Modify container images and deployment configurations to DROP ALL capabilities and ADD only the required minimal set (likely NET_BIND_SERVICE, potentially CHOWN). Validate all Quay modes function correctly.
3. Create Hardened Seccomp Profile: Develop a seccomp profile based on RuntimeDefault that restricts unnecessary syscalls while allowing Quay to function. Test with standalone podman deployments. Package profile for distribution.
4. Standalone Deployment Security Documentation: Create comprehensive documentation for applying security hardening to standalone (podman) deployments including seccomp profile application, capability restrictions, and recommended security options.
5. Integration Testing and Validation: Validate all Quay functionality with hardened security configuration. Test registry operations, worker processes, mirroring, and configuration modes with restricted capabilities and seccomp profile applied.

Dependencies

• Technical:
  • UBI9 base image compatibility for seccomp and capabilities
  • Understanding of Quay runtime requirements
• Cross-team:
  • Documentation team for security guide updates
  • Red Hat Product Security for seccomp profile review
  • QE for expanded security testing
• External:
  • None for this scoped effort

Success Criteria

• [ ] Container runs with DROP ALL capabilities plus documented minimal set
• [ ] All Quay modes (registry, config, repomirror, migrate) function with restricted capabilities
• [ ] Hardened seccomp profile published and validated for standalone deployments
• [ ] Documentation complete for standalone security hardening
• [ ] No regression in Quay functionality
• [ ] Seccomp profile validated against RuntimeDefault baseline

Technical Approach

Components Affected

• Dockerfile: Add capability restrictions, security context hints
• Quay Operator: Add capability drop configuration to deployments
• New file: seccomp-profile.json for standalone deployments
• Documentation: Security hardening guides

Key Technical Decisions

• Capability strategy: DROP ALL, ADD NET_BIND_SERVICE (for nginx port binding), evaluate CHOWN necessity
• Seccomp baseline: Use RuntimeDefault as starting point, customize as needed
• Distribution: Publish seccomp profile alongside container image documentation

Risks and Mitigations

• Risk: Required capability not identified during audit causing production failures
  Mitigation: Comprehensive testing across all Quay modes; staged rollout with monitoring
• Risk: Seccomp profile too restrictive blocking legitimate syscalls
  Mitigation: Base on RuntimeDefault; extensive testing; provide escape hatch documentation
• Risk: Breaking standalone deployments that don't apply recommended security options
  Mitigation: Clear documentation; backward-compatible defaults; explicit error messages

Testing Strategy

• Capability testing: Systematically test each Quay mode with DROP ALL, add capabilities one by one until functional
• Seccomp testing: Run full test suite with seccomp profile applied; capture blocked syscalls
• Standalone testing: Validate podman deployments with recommended security options
• Regression testing: Full integration and e2e test suite against hardened configuration

Rollout Strategy

• Capabilities: Can be applied as Dockerfile/Operator change; opt-out via securityContext override
• Seccomp profile: Published as optional for standalone; not enforced by default
• Backward compatibility: Existing deployments continue working; new features are additive
• Rollback plan: Remove securityContext restrictions; documented escape hatches

Documentation Needs

• Security guide: Minimal capability set documentation with rationale
• Standalone guide: Applying seccomp profile with podman
• Standalone guide: Recommended podman run options for security
• Troubleshooting: Common issues with security restrictions and solutions

Related Work

• Original Feature: PROJQUAY-9605
• Related: PROJQUAY-8703 (readOnlyRootFilesystem - separate epic)
• Related: PROJQUAY-9604 (UBI minimal base image - security synergies)