Worked Example: Azure and Cisco

Worked Example: Azure and Cisco¶

The rest of this section names responsibilities, not products. This page does the opposite, once. It takes one common stack and shows what Trusted Automation Execution looks like on it at full adoption, with every component of the reference architecture in place:

• Microsoft Entra ID and Azure for identity, secrets, build, hosting, and evidence
• NetBox and Cisco Catalyst Center for target context
• Cisco ISE, IOS XE, and IOS XR on the network side

Two things are worth looking for as you read. The first is how much of the architecture existing products already provide. The second, and more useful, is where they stop: the places where no product on the list does the job, and you have to build or configure something deliberately.

The Stack at a Glance¶

The one row with no product in it is the important one. Nothing on this list is an execution gateway. Ansible Automation Platform comes closest: it has role-based access, job templates, approval nodes, and an Azure Key Vault credential plugin. But verifying a signed artefact and asking an external policy engine before releasing credentials are still yours to add. Whatever you build or adopt, it is the most trusted component in the design, and it gets the strictest supply chain.

How the Pieces Connect¶

Two paths, kept deliberately apart. The publication path produces something the gateway can verify:

graph LR
    REPO[Azure Repos<br/>branch policies] --> BUILD[Azure Pipelines<br/>tests · GHAS · SBOM]
    BUILD --> SIGN[Protected signing stage<br/>cosign · key in Key Vault]
    SIGN --> ACR[Azure Container Registry<br/>signed image + provenance]

    style SIGN fill:#c8e6c9
    style ACR fill:#fff4e6

The execution path consumes it, and nothing on it can start without the gateway's decision:

graph TD
    RQ[Engineer · Pipeline · Agent] --> EN[Microsoft Entra ID<br/>Conditional Access · PIM · federation]
    EN --> GW[Execution gateway]
    ACR[Azure Container Registry<br/>signed image + provenance] --> GW
    CTX[NetBox · Catalyst Center · ServiceNow<br/>targets, state, approval] --> GW
    GW <-->|every decision| OPA[Open Policy Agent]
    GW -->|only after allow| AUTH[Cisco ISE + Azure Key Vault<br/>per-run device credential]
    AUTH --> RUN[Arc-enabled RHEL runner<br/>rootless Podman · SPIRE identity]
    RUN --> DEV[IOS XE · IOS XR<br/>ISE authorises every command]
    DEV --> VAL[Validation workload<br/>pyATS · Genie]
    VAL --> EV[Immutable Blob Storage<br/>Log Analytics]
    EV --> SEN[Microsoft Sentinel<br/>with ISE accounting]

    style GW fill:#c8e6c9
    style OPA fill:#c8e6c9
    style AUTH fill:#ffe0e0
    style RUN fill:#fff4e6
    style VAL fill:#e1f5ff
    style EV fill:#eeeeee

Component by Component¶

The groups follow the nine sentences, plus the tenth group from the architecture.

1. Prove who is asking¶

Why not use the runner's Azure Arc managed identity? Because it is one identity per machine. Every workload on the host would share it, and policy could no longer tell the audit workload from the change workload. That is the shared-service-account collapse again, one layer down. The Arc identity still has a job: it identifies the runner, for posture and telemetry.

One operational detail: Entra ID has to be able to fetch the SPIRE issuer's discovery document and public keys. Publish them somewhere Entra can reach. They are public keys; the signing keys never leave SPIRE.

2. Prove what will run¶

Verifying in two places is deliberate. The gateway's check is the decision. The runner's check means that a bug in the gateway, or someone starting a container directly on the runner, still cannot run an unsigned workload.

Where that second check lives needs care, because the formats are moving. Podman can enforce signatures itself, through a sigstoreSigned entry in its signature policy, but only for cosign's legacy signature format. Since cosign 3, the default is the newer Sigstore bundle format, attached through OCI referrers. As of October 2026, Podman cannot discover signatures in that format. Cosign can still write the legacy format, but the flag that does it is deprecated and due for removal in cosign 4.

The durable choice is to make the second check a cosign verify against the image digest in the runner's own launch step, before Podman is ever called. The same approach works if you standardise on Notation instead, which Podman's policy does not verify either. Move the check into Podman's policy once Podman reads the format you sign with.

3. Establish where it came from¶

The honest gap is provenance. Azure Pipelines has no built-in equivalent of GitHub's artifact attestations, so here the provenance is asserted by your own pipeline. That can be made trustworthy, but only by isolation: ephemeral build agents, a signing stage the build cannot influence, and protected service connections. Do not claim a SLSA build level you have not actually assessed.

4. Decide what it may do¶

The ServiceNow record is useful twice. At stage 6 it is a policy input. At stage 9, re-reading it is revalidation: an approval withdrawn in the meantime stops the run.

5. Constrain where it may do it¶

Two details in this group are easy to get wrong.

Read-only access to the source of truth matters. A workload that can edit NetBox can widen its own scope, by moving a device into a role it is allowed to touch.

Command sets govern the CLI only. NETCONF and RESTCONF sessions are not checked against TACACS+ command sets. Model-driven access needs its own rules, through the NETCONF Access Control Model, and task groups on IOS XR. A design that restricts the CLI carefully, then gives the same identity unrestricted NETCONF, has restricted nothing.

6. Grant only the authority required¶

This group holds the limit of the whole design. Network devices cannot accept short-lived tokens. TACACS+ authenticates a username and a password, so the best available pattern is a password that only works during the run: rotated per run, narrowed by command sets, and bound to device groups.

In ISE that rotation is an ordinary update to the internal user, through the ERS API. That means a PUT, or a PATCH from ISE 3.2, carrying the new password and the enabled flag. Writes go to the primary administration node, which replicates them to the policy service nodes that answer TACACS+, so allow for replication before the workload connects. Rotating the password in the same update that disables the account also avoids ISE's password history rejecting a re-sent old password.

Two failure cases need a deliberate answer:

• The ISE update fails. The run fails safe and does not start. It never falls back to a standing credential.
• Stage 12 never happens, because the gateway dies mid-run. A scheduled sweep disables any automation identity that is enabled without an active run, so the credential cannot outlive the gateway for long.

7. Execute within defined boundaries¶

The confirmed commit is the safeguard that survives the automation failing. If the runner, the gateway, or the network between them disappears mid-change, the device reverts on its own when the timer runs out. Every other safeguard on this page depends on something staying up. This one does not.

It still has to be tested, because the revert is only as good as the platform's implementation of it. Cisco's own IOS XE guides note cases where a revert can miss part of a configuration. Exercise a deliberate timeout on each platform and software release you automate, and treat a revert that does not restore the original state as a reason to keep that platform at a lower risk class until it does.

8. Validate the resulting state independently¶

The validator never borrows the change workload's identity or code. That is what makes it independent rather than a second opinion from the same author.

9. Prove what happened¶

The last detection is the one to build first. With per-run credential rotation, a workload identity logging in to a device outside a run should be impossible. So any occurrence is an incident, not noise.

10. Keep trust withdrawable¶

Revocation works at several layers. Any one of them is enough to stop a run, and each is fast:

Break-glass is designed in three places:

• Identity: Entra emergency access accounts, managed as Microsoft's guidance describes, with an alert on every sign-in. They exist for the day Entra-dependent controls lock everyone out.
• Devices: the local method in a device's AAA configuration is the device break-glass route. IOS falls back to it only when the TACACS+ servers do not respond, not when they refuse. Each device has a unique local account, held in a separate Key Vault behind PIM, rotated after every use. Every local login raises a Sentinel incident.
• Automation: a separate gateway path for emergency workloads, with its own identity, a stated reason, and narrowed scope. Artefact verification is never skipped. The ServiceNow emergency change is raised immediately, and every use is reviewed afterwards.

Governance ties it together. Each workload is registered as a service with its owners and risk class, as in the Automation Service Lifecycle. Entra access reviews recertify the requester groups and PIM eligibility. ISE command sets are reviewed against the accounting data, which shows exactly which permitted commands a workload has never used.

One Run, End to End¶

An R3 change to a batch of IOS XE access switches, requested by an engineer, through the fourteen stages of the execution lifecycle:

Variant: Kubernetes as the Runner¶

If you already run a hardened Kubernetes platform, it can replace the Arc-enabled RHEL hosts as the runner. That could be AKS, or an Arc-enabled cluster on-premises, closer to the devices; Red Hat OpenShift is among the supported distributions. Everything else on this page stays the same: the gateway still decides, ISE still enforces, and Key Vault still holds the per-run credential.

What changes:

The trust boundary moves, and this is the part to get right. In Kubernetes, anyone who can create a pod in a namespace can run it under any service account in that namespace. As far as Entra ID is concerned, they have become that workload. So:

• Only the gateway's own identity may create Jobs or pods in the automation namespaces. Nobody else may, including cluster administrators in their everyday role.
• exec into automation pods is denied. A shell inside a running workload is a shell holding its credential.
• Changes to the automation namespaces, their role bindings, and the admission policies go through the same review and approval as changes to the gateway itself.
• Cluster administration becomes a privileged role in its own right: PIM-gated, logged, and reviewed.

Where the cluster runs matters. AKS runs in Azure, so it needs private connectivity to your on-premises device management networks, and the egress rules above have to hold on that path as well. An Arc-enabled cluster on-premises sits next to the devices and keeps that path short, while Arc still brings it under the same Entra federation, Azure Policy, and Defender coverage.

Is it worth it? Kubernetes provides per-workload identity and per-run isolation more cheaply than the RHEL design does, but it adds a large platform to the trusted base. If you already operate a hardened cluster, it is a strong runner. If you do not, building one just for this adds more trusted surface than it removes.

What This Reaches, and What It Does Not¶

With everything above in place, this stack implements the Enterprise profile in full, and most of High-Assurance. Five things stand between it and the rest, and a design review should hear about them from you before it finds them itself:

1. Device authority is still a password. Rotated per run, narrowed by command sets, bounded by device groups — but not a capability-scoped token. That is a limit of TACACS+ and of the devices, not of the design.
2. Provenance is self-asserted. Your pipeline vouches for your build. Isolation makes that credible, but it is not the guarantee a hardened, hosted build platform provides.
3. Runner posture is reported, not hardware-rooted. Arc, machine configuration, and Defender report the runner's state. For High-Assurance, add TPM-based node attestation, which SPIRE supports, so that a runner's identity depends on its measured boot state.
4. The most trusted component is bespoke. The gateway and the OPA policies are your own code. They get the strictest supply chain on the page: the same signing, provenance, and separation of duties, applied first and hardest.
5. Availability is a dependency chain. Entra ID, Key Vault, ISE, ServiceNow, NetBox, and OPA all have to be up for privileged automation to run. That is the fail-closed cost, paid deliberately. Engineer each dependency for the availability you need, and exercise the break-glass routes before you need them.

None of these is a reason to stop short. Each is a known, stated residual risk, which is what a reference architecture is supposed to leave you with.

Continue¶

• Previous: Adoption Profiles
• Next: Proof of Concept v1
• Section index: Trusted Automation Execution