Private pilot

Deploy approval through a reviewed workflow integration

ORBIT has an internally proven GitHub Actions gate, but no public package or Action reference is available. Pilot use requires provisioning, tenant identity configuration, a reviewed workflow integration, and an exact-head smoke before the gate can be treated as enforcing.

Pilot status

Private pilot · provisioning and reviewed integration required. A copied example does not create deploy coverage.

The internal Action and receipt-bound gate have source proof. That is different from a customer-installable integration. ORBIT must provide an approved immutable artifact reference and verifier, bind the tenant’s GitHub OIDC identity, configure authentication, and prove the exact workflow seam before the page or dashboard may say a deploy is governed.

Authority sequence

  1. Request. The reviewed workflow step submits immutable deploy facts such as repository, commit, run, environment, artifact digest, and plan hash under the configured runner identity.
  2. Policy. ORBIT evaluates that exact request. Policy may allow, hold for a human decision, or block.
  3. Authorization receipt. If authority is granted, ORBIT commits a receipt bound to the exact request before the CI gate may release execution permission.
  4. CI verification. The provisioned verifier checks the expected signer boundary, decision, freshness, commit, environment, and artifact binding.
  5. Workflow continuation. Only the covered workflow path proceeds after the gate succeeds. The cloud provider or deploy tool reports execution separately.

An approved and verified authorization receipt does not prove that the downstream deployment started, completed, or changed the intended cloud resource.

Required provisioning

  • an ORBIT-provided Action artifact pinned to an approved immutable revision;
  • a checksum-pinned compatible verifier available on the runner;
  • tenant-specific GitHub OIDC issuer, audience, repository, workflow, and environment bindings;
  • the approved authentication path and secret handling for that tenant;
  • artifact digest and plan-hash producers whose outputs are bound to the later deploy step; and
  • an exact-head smoke proving the gate is immediately before the mutation and cannot be bypassed by ordinary workflow paths.

Non-runnable workflow shape

The following shows placement and bindings only. The placeholder cannot be installed until ORBIT provides the approved artifact reference and pilot configuration.

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@<approved-immutable-sha>

      # Build the exact artifact and plan before requesting authority.

      - name: Gate this exact deploy through ORBIT
        uses: <ORBIT-provided-action>@<approved-immutable-sha>
        with:
          oidc-audience: <tenant-provisioned-audience>
          environment: production
          artifact-digest: sha256:${{ steps.build.outputs.digest }}
          plan-hash: sha256:${{ steps.plan.outputs.hash }}

      # Runs only after the reviewed gate returns execution permission.
      - name: Deploy
        run: ./deploy.sh

Never add continue-on-error to the gate or create an alternate mutation path that skips it.

Fail-closed boundary

On the reviewed enforcing path, the gate stops workflow continuation when identity, request binding, policy, human decision, receipt commitment, verification, or required dependencies fail. This statement applies only to that covered workflow path; it does not claim that another workflow, credential, console, or deploy tool cannot mutate the environment.

Keep the authorization receipt beside the provider’s execution logs. They establish different facts: ORBIT authority versus what the deploy system actually did.

Later paths

  • Public GitHub Action or App. Directional until a supported package, distribution, tenant setup, and trust contract exist.
  • GitHub deployment protection. Directional; not an available environment rule today.
  • Other CI providers. Require their own workload-identity and exact mutation-seam integration.