FIX: eliminate KV public-access window for policy compliance

[hannahwestra25]

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

[behnam-o]

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?)

[hannahwestra25]

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?)

Good idea! My thinking is that this is a simple fix rn and nsp might be overkill since it's our only pain point — all our other resources are already created in a compliant state with publicNetworkAccess=Disabled and Private Endpoints. NSP would be a new resource to maintain for a problem that's otherwise just this one timing issue in the deploy script.

That being said, NSP might be something we would want to go with in the future (esp because I don't think it's too much work). I can create a follow up work item to migrate to it but wdyt ?

[behnam-o]

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?)

Good idea! My thinking is that this is a simple fix rn and nsp might be overkill since it's our only pain point — all our other resources are already created in a compliant state with publicNetworkAccess=Disabled and Private Endpoints. NSP would be a new resource to maintain for a problem that's otherwise just this one timing issue in the deploy script.

That being said, NSP might be something we would want to go with in the future (esp because I don't think it's too much work). I can create a follow up work item to migrate to it but wdyt ?

makes sense. Yeah let's do a follow up to add NSP in the ARM template, and hook it up to other resources too.