Skip to content

FIX: eliminate KV public-access window for policy compliance#2049

Draft
hannahwestra25 wants to merge 1 commit into
microsoft:mainfrom
hannahwestra25:hannahwestra25/fix-keyvault-policy-compliance
Draft

FIX: eliminate KV public-access window for policy compliance#2049
hannahwestra25 wants to merge 1 commit into
microsoft:mainfrom
hannahwestra25:hannahwestra25/fix-keyvault-policy-compliance

Conversation

@hannahwestra25

Copy link
Copy Markdown
Contributor

Problem

The deploy script creates Key Vault with publicNetworkAccess=Enabled, writes a secret, then locks it down. This creates a temporary violating state that will be blocked once Azure policy enforcement rolls out (per the recent IcM alert).

Fix

Create the KV with defaultAction=Deny and only the deployer's public IP allowlisted from the start. After the secret is written:

  1. Remove the deployer's IP rule
  2. Disable publicNetworkAccess entirely

The KV is never in an unrestricted public access state, so the policy will not block it.

Changes

  • infra/deploy_instance.py: Detect deployer IP via ipinfo.io, create KV locked down with IP allowlist, remove IP rule after secret write
  • infra/README.md: Updated docs to reflect new approach

Create Key Vault with defaultAction=Deny and only the deployer's IP
allowlisted (instead of unrestricted public access). After the secret
is written, remove the IP rule and disable publicNetworkAccess entirely.

This eliminates the temporary violating state where the KV had
publicNetworkAccess=Enabled, avoiding blocks from Azure policy
enforcement that rejects resources created in a non-compliant state.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@hannahwestra25 hannahwestra25 changed the title fix(infra): eliminate KV public-access window for policy compliance FIX: eliminate KV public-access window for policy compliance Jun 18, 2026
@behnam-o

behnam-o commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Another way to consider dealing with this is by deploying a Network Security Perimeter and associating the AKV to it. That means, even with publicaccess=True on the AKV, it is still bound by the rules in the NSP and satisfies net isolation requirements.

that also has the benefit of letting us associate it to other resources too (I think the ACR, ACA, etc. all need some sort of net-iso policy? all of those should be satisfied with a NSP)

(and I don't think we're doing that for the persistent copyrit deployments, and instead using a general NSP used on all our stuff ... maybe we should do this for copyrit nonprod+prod too?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants