# Pattern: Secure Cluster Baseline

Status: seed
Readiness target: RL3 production
Primary owners: Railiance platform
Genesis family: Kubernetes and platform

## Problem

Production Kubernetes clusters inherit unsafe defaults unless baseline
hardening is explicit, versioned, and verified.

## Context

Use this pattern for every cluster class that hosts platform services,
tenant workloads, identity services, secret managers, or production
applications.

## Forces

- Kubernetes exposes many powerful APIs by default.
- Platform add-ons need privileged access but must be bounded.
- Baseline controls must survive upgrades.
- Product teams need predictable guardrails.

## Solution

Define a secure cluster baseline covering API server settings, RBAC,
node hardening, pod security, admission, network policy, secret
handling, audit, backups, and upgrade posture.

## Verification

- Cluster baseline checks run before production admission.
- Privileged Kubernetes APIs are limited and reviewed.
- Audit logging, backup, and restore paths are enabled.
- Upgrade tests verify baseline controls remain active.

## Related Patterns

- Pod Security Baseline/Restricted.
- Policy-as-Code Admission Control.
- Network Default Deny.
- Runtime Threat Detection.