Skip to main content
Version: v5.7.0

13.4 Lab: how OpsChain governs integrations

Included from Basic tierintegrations:githubintegrations:jira-service-management

After this you can: state the three rules every OpsChain integration follows — signed inbound, just-in-time outbound, every crossing audited — and read any new integration against them.

Before you start — tick each one:

  • Lesson 13.1 — GitHub (opschain learn 13.1)
  • Lesson 13.2 — Jira Service Management (opschain learn 13.2)
  • Lesson 13.3 — SIEM export (opschain learn 13.3)

In the GUI: Integrations in the Operations area lists every connection with its deliveries and health; the Events screen shows each crossing.

Every integration OpsChain ships follows the same three rules. Each lesson of this module is one application of them; this lab states them once and asks you to find each rule in the integrations you just built. No new verbs: every answer comes from a command a lesson taught.

1. Inbound calls arrive signed, never trusted​

An external system never holds an OpsChain session. Inbound deliveries authenticate cryptographically — an HMAC signature on a webhook delivery (opschain docs inbound-webhooks), an OIDC token exchange under a declared trust policy for GitHub Actions (lesson 13.1) — and a verified delivery acts as a declared service account, never with ambient authority. An unverifiable delivery is refused by name.

Find it: show the trust policy your GitHub connection binds the exchanged token to, and the identity a verified webhook delivery acted as.

2. Outbound credentials are issued just in time​

OpsChain does not park long-lived credentials in external systems, and does not let secrets rest where work is defined. Outbound access is brokered at the moment it is needed: short-lived tokens scoped to the caller, one-shot transport sessions minted per admitted step (opschain docs transport-providers, lesson 6.4), model keys brokered to agents rather than copied out (lesson 12.6). When the work ends, there is nothing left to steal.

Find it: show the just-in-time GH_TOKEN lesson 13.1 retired the stored token for, and say where it does not exist once the run has ended.

3. Every crossing is audited​

Whatever direction the traffic flows, the crossing lands on the events stream like any other governed action: who or what called, under which identity, what it read or wrote. The SIEM export (lesson 13.3) streams that record outward, and the JSM write door (lesson 13.2) writes evidence back to the system that asked for the work.

Find it: from the events feed, list the crossings your three integrations made in this module, and show the ticket note the JSM door wrote.

4. Reading an integration with these rules​

When you meet a new integration, ask three questions: where does its inbound trust come from, why does no standing credential exist, and where is the crossing recorded? If you can answer all three, you understand the integration; if one has no answer, something is wrong with the design or the configuration.

Check yourself​

  • For each of the three integrations you built: where does its inbound trust come from, why does no standing credential exist, and which event records the crossing?

What you learned​

  • Inbound deliveries authenticate cryptographically and act as a declared service account, never with ambient authority.
  • Outbound access is brokered just in time and leaves nothing behind.
  • Every crossing is on the events stream, exportable to your SIEM and written back as evidence where the work was asked for.

Next: this closes the module Integrations — back to your track (opschain learn).