Securing ILAP Analytics — playbook overview

Modified on Wed, 12 Aug at 1:19 PM

The step-by-step procedure for securing an environment ships inside the deployment package, as Azure.IaC/Reference-Security/PLAYBOOK.md. It is versioned alongside the templates it describes, so the copy in your download always matches the templates you downloaded — which is why it is not reproduced here.

This page is the map. It exists so you can plan the work and line up the people before you open the archive: what the playbook covers, in what order, and what has to be in place first. It is written for the IT administrator planning the hardening of an ILAP Analytics environment.

Secure an environment only after the ordinary installation is deployed and verified. See Securing ILAP Analytics — reference example for what the reference protects and why, and the Installation Overview for the install sequence and the full authorization matrix.

What you need before you start

Several of these are owned by different teams in organisations with segregated duties, and that is usually what sets the pace. Agree who holds each one before you begin.

What	Why it is needed	Typically owned by
A VNet address range that does not clash with your existing networks	The deployment creates the virtual network and its subnets. The range cannot be changed afterwards without redeploying	Network team
An existing Key Vault holding the TLS certificate	The templates reference the vault as existing and never create it. The deployment fails if it is absent	Security / Key Vault owners
The two app registrations (API and UI)	Authentication. Created by hand in Entra ID, not by the templates	Identity / Entra ID administrators
A nominated Entra SQL administrator	The server is Entra-only. This person signs in to each database and runs the grant script	Database administrator
DNS records for any custom domains	Custom hostnames on the App Services	Network / DNS team
A path into the virtual network — corporate network, VPN, or ExpressRoute	Once the private endpoints exist, the apps have no public URL. Without a path in, you cannot reach them or deploy to them	Network team
If you have no corporate network yet: a Tailscale account and two credentials	The optional test-access subnet router. The two credentials are unrelated despite both being called "key" — see below	You

The two Tailscale credentials

Only relevant if you use the optional test-access router. They come from different places and only one is yours to generate:

tailscaleAdminSshPublicKey — an ordinary SSH public key you generate (ssh-keygen -t ed25519). It is for break-glass admin through the serial console when Tailscale itself is down. Generate it up front: the moment you need it is the moment you cannot add one.
tailscaleAuthKey — an enrolment token from the Tailscale admin console. Keys are single-use. One carried over from another environment, or revoked after it enrolled a router, is dead — and a spent key is indistinguishable from a good one in a parameter file. The deployment succeeds, the machine runs, and the router simply never appears in your tailnet. Generate a fresh one for each deployment.

The steps

Step	What happens	Why it matters
0	Decisions: address space, whether the Autonomous Component is in scope, whether you need test access	The address range and the environment naming are set here and are painful to change later
1	Key Vault	Must already exist. The templates reference it and never create it
2	Deploy ILAP Analytics	The ordinary installation, still publicly reachable
3	Deploy the Autonomous Component (optional)	Only if it is part of your environment
4	Grant the managed identities database access	Nothing in the templates does this. Until it is done the apps cannot reach the database
5	Deploy the application code and confirm it works	Before step 6, not after — see below
6	Deploy the reference security infrastructure	Virtual network, private endpoints, private DNS. The App Services become private-only here
7	Establish and verify the private path	DNS forwarders and firewall rules are often another team's work with a long lead time. Raise the request before you reach this step
8	Verify connectivity before hardening	A read-only script that needs no access to the private network
9	Harden	Disables public network access on SQL, Key Vault and storage
10	Verify after hardening	Re-runs the checks and the application sign-in
11	Upgrades	A later redeploy can silently reopen what you closed

Two ordering facts that catch people out

The apps go private before you harden them. Creating a private endpoint for a web app sets its publicNetworkAccess to Disabled automatically — so the API, UI and Background Jobs apps become private-only, including their SCM/Kudu endpoints, the moment step 6 completes. That is three steps before the hardening in step 9. Any deployment method that uploads through Kudu, including az webapp deploy and most CI/CD pipelines, stops working from a public machine at that point, and the failure presents as a timeout that reads like a build problem. This is why step 5 comes first.

Verify before you lock down. Disabling public network access on an environment whose private path is not yet working strands the apps from their dependencies and from SSH. Steps 7 and 8 exist to prove the private path works while you still have a way back in.

When something looks configured but does not work

The playbook ends with a table called Things that fail silently — every row was observed on a live deployment, and none of them produces an error message. If a step appears complete and the result is wrong, read that table before anything else. The package also ships a troubleshooting guide and read-only diagnostic scripts under Azure.IaC/Reference-Security/, including one that runs from an admin machine and needs no access to the private network, so it still works when the environment is fully locked down.