Examples

The operator's source tree ships three reference scenarios under tools/k8s-operator/examples/. Pick the one closest to your shape and adapt.

1. GitLab CI runner with materialised token

Use case: a GitLab Runner pod that needs to push to an OrbitalReg Maven repo, with the bearer token materialised into a Secret the runner consumes via envFrom.

---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegProject
metadata:
  name: acme
spec:
  slug: acme
  displayName: "Acme Corp"
  ownerEmails: [platform@acme.example.com]
---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegRepository
metadata:
  name: acme-internal-maven
spec:
  projectRef: { name: acme }
  slug: internal-maven
  format: maven
  kind: local
---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegServiceAccount
metadata:
  name: gitlab-runner
spec:
  projectRef: { name: acme }
  name: gitlab-runner
  scopes: ["push:project:acme:repo:internal-maven"]
---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegServiceAccountToken
metadata:
  name: gitlab-runner-token
  namespace: gitlab-runners
spec:
  serviceAccountRef: { name: gitlab-runner }
  name: gitlab-runner-token
  scopes: ["push:project:acme:repo:internal-maven"]
  expiresIn: 90d
  secretName: orbitalreg-creds

The runner Pod consumes the materialised Secret:

- name: gitlab-runner
  envFrom:
    - secretRef:
        name: orbitalreg-creds
  # → ORBITALREG_TOKEN, ORBITALREG_ENDPOINT now in env

Rotation: bumping spec.expiresIn triggers a rotation. The new plaintext lands in the same Secret; the runner picks it up on next restart.

2. SOC team driving security blocks + HMAC webhooks

Use case: a security operations team that owns an in-cluster GitOps repo declaring every active block plus an HMAC-signed webhook subscription for downstream incident-response automation.

---
apiVersion: v1
kind: Secret
metadata:
  name: soc-hmac
  namespace: orbitalreg-operator
type: Opaque
data:
  secret: <base64 of 32-byte random>
---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegSecurityBlock
metadata:
  name: malicious-2025-0042
spec:
  blockType: sha256
  pattern: "9f86d081…"
  reason: "Confirmed-malicious sample from FAS-2025-0042"
  customerMessage: |
    Blocked by SOC. Reach out to security@acme.example.com for
    triage.
  active: true
---
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegWebhookSubscription
metadata:
  name: soc-incident-response
spec:
  url: https://soc.acme.example.com/incidents
  hmacSecretRef:
    name: soc-hmac
    namespace: orbitalreg-operator
    key: secret
  events:
    - finding.threshold-exceeded
    - block.created
    - block.hit

Rotating the HMAC secret is a Secret-level update; the next reconcile pass detects the bumped resourceVersion and PATCHes the upstream subscription.

3. Multi-tenant platform with per-tenant retention + CVE blocks

Use case: a platform team running OrbitalReg as a shared service with three downstream tenants, each owning a different retention grammar and a per-repo CVE block.

---
# Tenant A — keep snapshots for 7 days
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegRetentionPolicy
metadata:
  name: tenant-a-snapshots
spec:
  repositoryRef: { name: tenant-a-maven-snapshots }
  name: snapshots-keep-7d
  rules:
    - keep_by_age:
        max_age_days: 7
        match_path_regex: "-SNAPSHOT/"
---
# Tenant B — keep last 5 versions per package
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegRetentionPolicy
metadata:
  name: tenant-b-keep-5
spec:
  repositoryRef: { name: tenant-b-npm }
  name: keep-5-newest
  rules:
    - keep_n_newest:
        n: 5
---
# Tenant C — keep tagged dist-tags + last 30 days
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegRetentionPolicy
metadata:
  name: tenant-c-keep-tagged
spec:
  repositoryRef: { name: tenant-c-npm }
  name: keep-tagged-30d
  rules:
    - keep_dist_tagged: ["latest", "next"]
    - keep_by_age:
        max_age_days: 30
---
# Per-repo CVE block scoped to tenant-c only
apiVersion: orbitalreg.io/v1alpha1
kind: OrbitalRegSecurityBlock
metadata:
  name: tenant-c-cve-2025-1337
spec:
  blockType: cve
  pattern: "CVE-2025-1337"
  repoRef: { name: tenant-c-npm }
  reason: "Auto-block per platform CVE policy"
  active: true

Each tenant manages its own folder under argo-apps/tenant-<x>/ and ArgoCD reconciles. The OrbitalReg operator picks up the CRs and keeps the upstream rows in sync.

What's not a good fit for the operator

• One-shot operations — promotions, build trigger, on-demand scans. Use the REST API or Terraform provider.
• Mass-import — bulk-upload of pre-existing artifacts. Use the Mass Import flow under Admin → Imports.
• Per-user permissions — the operator manages service accounts; human-user RBAC stays in the admin UI / SAML group mapping.