witnora

Credential-Gated Promotion Enforcement v0.2

Witnora turns a reviewed Promotion Grant into a short-lived, single-use deployment credential. The credential is bound to one project, mutation, artifact SHA-256, deployment target, adapter, and authenticated principal. Possessing a Promotion Grant alone is not sufficient to deploy.

This name is intentionally narrower than the legacy filename. The mechanism enforces only registered deployment boundaries; unmanaged credentials and undeclared deployment paths remain outside its claim.

Enforcement chain

1. A human owner or administrator reviews an agent mutation and issues a Promotion Grant.
2. GitHub Actions presents its OIDC identity to the Witnora credential broker.
3. The broker verifies issuer, audience, repository, workflow, and source commit claims, atomically consumes the grant, and returns a credential valid for 30 to 900 seconds and one use.
4. The customer-owned deployment boundary claims that credential before it accepts the exact artifact digest for the exact target.
5. Witnora records a server-signed admission or denial event. The bearer token is returned once and only its SHA-256 digest is retained.

Register a project identity provider with these constraints before the first workflow exchange:

{
  "name": "GitHub Actions deployment",
  "kind": "OIDC",
  "vendor": "STANDARD",
  "issuer": "https://token.actions.githubusercontent.com",
  "jwksUri": "https://token.actions.githubusercontent.com/.well-known/jwks",
  "audiences": ["witnora-deployment-broker"],
  "allowedAlgorithms": ["RS256"]
}

Use Kakarottoooo/witnora/actions/promotion-enforcement@v0.9.3 in a protected GitHub Environment for the reference GitHub flow. Use witnora/deployment-enforcement for a customer gateway or the Kubernetes AdmissionReview handler. The Kubernetes reference requires digest-pinned container images and the following workload annotations:

• witnora.com/deployment-credential-id
• witnora.com/artifact-digest-sha256
• witnora.com/deployment-uri

The reference deployment is in examples/deployment-enforcement/kubernetes/deployment.yaml.

Failure behavior

• no credential: reject;
• expired, revoked, or already consumed credential: reject;
• artifact, target, or adapter mismatch: reject;
• OIDC repository or commit mismatch: reject;
• admission retry with the same idempotency key: return the original result without consuming again or creating a duplicate event;
• reuse with a different idempotency key: reject as replay.

Rollback credentials are owner/admin operations and bind only the declared parent digest. Break-glass credentials are owner-only, short lived, limited to the declared parent or candidate, and immediately suspend continuous assurance. Both operations create signed enforcement events and require independent revalidation before assurance can return to CURRENT.

Security boundary

GitHub Environment approval protects the workflow entry point. It is not, by itself, a cluster or cloud authorization boundary. Production deployments must place credential admission in a customer-controlled gateway, Kubernetes admission webhook, or equivalent cloud deployment adapter whose service account is the only principal allowed to mutate the target.

This protocol proves that Witnora admitted one declared artifact and target under one verified identity and one bounded authorization. It does not prove that an administrator could not bypass an incorrectly configured customer IAM policy, that the application behaved correctly after deployment, or that the deployed bytes remained unchanged. Independent outcome and deployed-artifact probes remain required.

This site is open source. Improve this page.