CI gates and Polaris — the prevention strategy

CI gates and Polaris are the prevention strategy. The CI pipeline catches the anti-patterns; the Polaris audit scores the manifests. The gate runs before the cluster is touched, so a defect costs a pipeline run rather than a rollout.

The CI pipeline

The CI pipeline is the cluster’s prevention layer. The CI pipeline validates the manifests before they are applied to the cluster.

flowchart LR
    A[Git repo] --> B[CI pipeline]
    B --> C{Polaris audit}
    C -->|Pass| D[GitOps controller]
    C -->|Fail| E[CI failure]
    D --> F[Staging cluster]
    F --> G[Production cluster]

The CI pipeline is the cluster’s prevention.

The Polaris audit

The Polaris audit is the cluster’s anti-pattern detection. The Polaris audit scores the manifests on a set of best practices.

# Run the Polaris audit
polaris audit --format yaml > polaris-report.yaml

# Run the Polaris audit with a config
polaris audit --config polaris-config.yaml --format yaml > polaris-report.yaml

A real Polaris report:

- name: billing
  results:
  - id: hostNetworkSet
    message: Host network is not configured
    severity: warning
    category: Networking
  - id: imagePullPolicyNotAlways
    message: Image pull policy is not set to Always
    severity: warning
    category: Reliability
  - id: priorityClassNotSet
    message: Priority class is not set
    severity: warning
    category: Scheduling

The Polaris report is the cluster’s anti-pattern detection.

The policy as code

The policy as code is the cluster’s governance. The policy as code is the source of truth for the cluster’s standards.

# Polaris config
checks:
  hostNetworkSet: warning
  imagePullPolicyNotAlways: warning
  priorityClassNotSet: warning
  runAsNonRoot: error
  readOnlyRootFilesystem: warning

The policy as code is the cluster’s governance.

The diagnostic

The canonical diagnostic:

# 1. Run the Polaris audit
polaris audit --format yaml > polaris-report.yaml

# 2. Check the Polaris report
cat polaris-report.yaml

# 3. Check the CI pipeline
# (CI pipeline-specific)

# 4. Check the GitOps controller
kubectl get applications -n argocd

# 5. Check the cluster's state
kubectl get deployments -A

The diagnostic is the Polaris audit, the CI pipeline, the GitOps controller, and the cluster’s state.

Common failures

• CI pipeline missing. The CI pipeline does not validate the manifests. The remediation is to add the CI pipeline.
• Polaris not configured. The Polaris audit is not configured. The remediation is to configure Polaris.
• Policy too permissive. The policy is too permissive. The remediation is to tighten the policy.
• Policy too strict. The policy is too strict. The remediation is to relax the policy or fix the manifests.

flowchart TD
    A[CI gates failing] --> B{CI pipeline missing?}
    B -->|Yes| C[Add the CI pipeline]
    B -->|No| D{Polaris configured?}
    D -->|No| E[Configure Polaris]
    D -->|Yes| F{Policy too strict?}
    F -->|Yes| G[Relax the policy]
    F -->|No| H[Unknown]

The remediation

The remediation depends on the failure:

# Option 1: Add the CI pipeline
# (CI pipeline-specific)

# Option 2: Configure Polaris
polaris audit --config polaris-config.yaml

# Option 3: Tighten the policy
# (policy-specific)

# Option 4: Relax the policy
# (policy-specific)

The remediation is the prevention.

Production discipline

CI gates and Polaris are the cluster’s hypothesis. The discipline is the same scale-free: every manifest is validated before it is shipped. The Polaris audit is the cluster’s anti-pattern detection; the CI pipeline is the cluster’s prevention.

• Configure Polaris. The audit scores the manifests against the policy file that polaris audit --config polaris-config.yaml reads.
• Tighten the policy. The policy is the cluster’s governance; the Polaris config grades each check as warning or error.
• Run the audit before the GitOps controller applies. A manifest rejected in the pipeline never reaches the API server.

Quiz