Security And Sensitive Data

Committed design

Security decisions must be visible in the plan before Azure or a guest operating system is changed.

Trust surfaces

Surface	Main risks	Control intent
Operator workstation	Command history, local files, cached tokens	Keep secrets out of YAML and logs; redact reports; use short-lived sign-in
CI runner	Untrusted pull requests, broad cloud access, retained logs	Protected environments, OIDC, least privilege, no cloud credentials on forked PRs
Azure control plane	Excessive RBAC, public endpoints, drift	Scoped roles, policy checks, private access where practical, Azure-aware `-WhatIf`
VM or container guest	Privileged installers, secret exposure, lateral movement	Minimize guest privileges, verify artifacts, probe installed state
Data and artifact sources	Tampering, malicious installers, unclear provenance	Pin versions, verify checksums or signatures, record owner and license
Run state and reports	Secret or sensitive-data leakage	Versioned schemas, redaction, access control, retention rules
Teardown	Deleting shared resources or leaving chargeable data behind	Ownership-aware deletion, confirmation, and cleanup proof

Secret-store decision for every solution

The committed baseline is Microsoft Entra authentication and managed identities where the target supports them. Every identity will receive only the permissions required for its operation. The plan must show the identity, scope, role assignments, and lifecycle before execution.

Every target provider and solution pack must emit exactly one secretStoreDecision:

Decision	Meaning
`deploy-key-vault`	Create an owned Azure Key Vault through the reusable capability module
`reuse-key-vault`	Use an existing vault without silently taking teardown ownership
`approved-external-store`	Use another approved store through an explicit adapter and policy decision
`not-applicable`	Record why the target or pack has no secret value to store

Azure Key Vault is the default Azure secret boundary, but the provider does not embed the vault implementation. The Key Vault capability records Azure RBAC, network restrictions, soft delete, purge protection, auditing, retention, ownership, and teardown behavior.

The decision appears in Plan, WhatIf, cost, security, ownership, and teardown evidence. YAML, command history, normalized plans, run state, logs, and reports contain references rather than secret values. not-applicable is never an implicit default and always needs a recorded rationale.

Password creation and password display are separate high-risk choices:

-GeneratePassword opts in to toolkit-side generation when an approved secret does not already exist.
-ShowPassword independently opts in to printing the value in the shell.
one flag will never imply the other;
both default to off, and non-interactive runs must make either choice explicitly.

Shell output can survive in scrollback, transcripts, screenshots, support bundles, and CI logs. Outside the one explicitly requested interactive display, redaction must remain active in terminal messages, JSON, Markdown, and HTML outputs.

Administrative access decision for every VM

Public SQL, SSH, and RDP endpoints are not part of the intended default. A plan will show private endpoints, DNS, network security rules, operator access, and every requested public exception.

Every Azure VM must emit an administrativeAccessDecision. The default is Azure Bastion with no public IP. Reusing an existing Bastion instance or opting out requires a rationale and explicit approval. The decision, selected tier, continuing cost, network effect, and public-access exception appear in Plan, WhatIf, cost, and security evidence.

Developer, Basic, Standard, and Premium tiers have different connection, scale, peering, recording, and private-only capabilities. A provider requests the Bastion capability; it does not implement Bastion internally. VM-hosted containers inherit the same decision. Managed container platforms do not because they do not expose a VM administrative surface.

Execution and state

Protected interactive runs may use local state. CI, webhooks, or other unattended mutation require encrypted remote state with authenticated locking, monotonically increasing fencing tokens, resumable events, and short-lived OIDC or managed-identity authentication. A local file lock cannot coordinate independent runners safely.

Sensitive data

ContainsSensitiveData is a required acknowledgement for real or restricted data. It is not a compliance certificate, a classification engine, or permission to bypass policy.

The acknowledgement will activate checks for permitted subscriptions and regions, encryption, key ownership, public access, diagnostic data, report redaction, backup and snapshot retention, access review, and deletion evidence. The organization that owns the data remains responsible for classification, legal basis, policy, and compliance.

Artifact supply chain

Every downloadable tool, script, installer, backup, model, or private artifact needs:

an authoritative owner and source;
license and redistribution status;
an immutable version or release identifier where available;
a publisher signature or expected checksum where available;
user-supplied checksum support for private paths and URLs;
required execution privilege and compatibility;
acquisition, installation, verification, and removal evidence.

A checksum mismatch must fail closed. Mutable URLs and artifacts without integrity evidence need an explicit warning and approval. Catalog inclusion is not an endorsement.

CI identity

The committed GitHub design uses OpenID Connect federation instead of stored Azure client secrets. Trust conditions must bind the identity to the expected repository, branch or environment, and workflow context. Protected environments will gate live deployments and teardown.

Secret scanning, dependency review, infrastructure scanning, PowerShell analysis, Pester, and vulnerability scanning remain backlog controls until their workflows exist and publish evidence. See Git And CI/CD.