SC-500 Application Platform Security: AKS, Containers, Functions, App Service, WAF and API Management

Defender for Containers protects container workloads with a mix of agentless components and one in-cluster sensor, and which detection you get depends on which component is running. Registry scanning, cluster discovery and Kubernetes audit-log analysis need nothing installed in the cluster. Anything that has to watch processes inside running containers needs the Defender sensor.

Each component covers its own signal, so a missing alert type points at the component that produces it: runtime threats seen inside a node, such as a malicious process, need the sensor, while vulnerability findings and control-plane alerts arrive without it. Container insights (Azure Monitor) is a monitoring feature, not a Defender threat-detection component.

Blocking risky workloads at admission

Two controls stop a deployment before it runs, and they decide on different evidence:

• Azure Policy for Kubernetes decides on the pod specification. Assign a built-in definition such as "Kubernetes cluster should not allow privileged containers" with the Deny effect and the API server rejects a privileged pod spec; with Audit it only reports. A policy that restricts images to allowed registries controls where an image comes from, not whether it is vulnerable.
• Gated deployment decides on the image's vulnerability findings. Defender for Cloud security rules (audit or deny) are evaluated at admission against the findings that agentless registry scanning already produced, so an image with critical CVEs can be stopped at deploy time. It needs both the registry findings and the sensor, which performs the admission check.

Other runtime and posture tools act at different moments: binary drift blocking stops unexpected executables from running inside a container after it starts, and the Defender CSPM cloud security explorer and attack paths find and prioritise risk but never reject a request. Node-level scanning by Defender for Servers covers the node VM operating system, not the container images deployed to it.

Securing access to an AKS cluster means making Microsoft Entra ID the only way in (authentication) and deciding what each identity may do inside the cluster (authorization). Entra integration lets users sign in with their Entra accounts, so Conditional Access and account disablement apply to them.

Local accounts and the admin kubeconfig

Every AKS cluster also has a local cluster-admin account. az aks get-credentials --admin downloads a kubeconfig holding a certificate that is not tied to any Entra identity, so disabling a person in Entra does nothing to it. To make Entra the only path:

• Run az aks update --disable-local-accounts (Entra integration must be enabled). No new admin kubeconfig can then be retrieved.
• On an existing cluster, also run az aks rotate-certs. Microsoft documents this step because certificates issued earlier keep working until the cluster certificates are rotated. Rotation alone isn't enough either: with local accounts still enabled, anyone with the right Azure role can download a fresh admin kubeconfig.

Removing someone's Azure Kubernetes Service Cluster Admin Role assignment only stops future downloads of the admin kubeconfig; a certificate already on a laptop keeps working.

Azure RBAC for Kubernetes authorization

With Azure RBAC enabled for Kubernetes authorization, Azure role assignments grant data actions on Kubernetes objects (for example Microsoft.ContainerService/managedClusters/pods/read), and they can be scoped to the whole cluster or to one namespace (<cluster resource ID>/namespaces/<name>).

The generic Azure Reader role has control-plane read actions only, so it cannot list pods. A Kubernetes Role and RoleBinding can grant the same rights, but they are managed inside the cluster, not as Azure role assignments; choose them when the requirement is Kubernetes RBAC, and the AKS RBAC roles when access must be governed in Azure. Users typically still need the Cluster User Role (or an equivalent) to fetch a kubeconfig.

AKS network security has two layers: how the API server (control plane) is exposed, and which pods may talk to each other. Workload identity then decides how pods authenticate to Azure services without stored secrets.

API server: private cluster vs authorized IP ranges

The managed control plane isn't in the node subnet, so an NSG on that subnet doesn't change API server exposure. Disabling local accounts is an identity control and doesn't restrict network sources.

Pod-to-pod traffic: Kubernetes network policies

Network policies select pods by label and namespace and allow or deny traffic between them, including pods on the same node. They need a policy engine, such as Azure CNI powered by Cilium or Calico. NSGs and Azure Firewall work at subnet, NIC or egress boundaries and can't see pod labels or traffic inside a node. Pod Security Admission restricts what a pod spec may request (privileges, host access); it doesn't filter connections.

Microsoft Entra Workload ID

Workload ID lets one pod obtain an Entra token for one managed identity (or app registration) through identity federation, with no secret stored in the cluster. It replaced pod-managed identity, now deprecated and retired, (AzureIdentity and AzureIdentityBinding). The pieces:

1. Enable the cluster's OIDC issuer and workload identity (--enable-oidc-issuer --enable-workload-identity).
2. Create a Kubernetes service account annotated with the identity's client ID (azure.workload.identity/client-id).
3. Add a federated identity credential on the identity with the cluster's issuer URL, subject system:serviceaccount:<namespace>:<service-account> and audience api://AzureADTokenExchange.
4. Label the pod azure.workload.identity/use: "true". The mutating webhook then injects variables such as AZURE_FEDERATED_TOKEN_FILE and the projected token.
5. Grant the identity its data role, for example Key Vault Secrets User.

Troubleshooting follows that order. If the token file is injected, the webhook and label worked. An Entra error such as AADSTS70021 (no matching federated identity record) means the issuer, subject or audience in the federated credential doesn't match what the pod's token carries; compare each of the three values character for character. A missing role shows up later, as an authorization error from the target service after a token was issued. Avoid the kubelet managed identity for application access: every pod on the node can use it.

Azure Container Registry security comes down to authenticating pulls and pushes with Entra identities at least privilege, and closing network access, which needs the Premium tier.

Authentication options

Contributor on the registry adds management rights and is never the least-privilege answer for pulling or pushing.

Network controls are Premium-only

Private endpoints, public IP network rules, service endpoint access (preview) and customer-managed keys require the Premium tier. To give build agents a private IP path and close the internet: move to Premium, create a private endpoint, then disable public network access. IP rules only filter the public endpoint, and the service-endpoint option still targets the registry's public address. The Allow trusted Microsoft services exception lets selected Azure services (for example ACR Tasks or Defender scanning) bypass network rules; it gives your own clients no private path.

Container Instances (ACI) and Container Apps run containers without a cluster to manage, so their security controls are settings on the container group or app: how secrets reach the container, whether it is on a virtual network, and who can reach its endpoint.

Azure Container Instances

• Secure environment variables (secureValue in YAML, --secure-environment-variables in the CLI) reach the container as normal environment variables but aren't returned in the container group's properties in the portal or az container show. A plain value is visible there.
• Secret volumes deliver values as files (backed by tmpfs) mounted into the container. Use them when the app reads files; they don't satisfy an app that must read an environment variable. Azure Files mounts also deliver files and put data in a storage share.
• Virtual network deployment: a container group deployed into a subnet delegated to Container Instances gets a private IP and no public IP, and can reach private endpoints in that network. A service endpoint doesn't put the group inside the VNet.
• Managed identity (system- or user-assigned) authenticates the container to Key Vault, Storage or ACR without stored credentials. It solves authentication, not network reachability.

Azure Container Apps ingress

Two settings combine. The environment is external (public load balancer) or internal (internal load balancer in your VNet). Each app's ingress is either:

Further per-app controls:

• IP ingress restrictions: per-app allow or deny rules for source IP ranges (all rules on an app use the same mode). They restrict one app while its neighbours stay public; an NSG on the environment subnet would affect every app in the environment.
• Built-in authentication (Easy Auth) requires sign-in with an identity provider; it checks identity, not source address.
• Key Vault reference secrets: define an app secret whose value is a Key Vault secret URI read with the app's managed identity, then map it to an environment variable with secretRef. The identity needs only Key Vault Secrets User (RBAC model); Secrets Officer adds write and delete. A versionless URI lets the app pick up new versions automatically (Microsoft documents within about 30 minutes) and restarts revisions that use it as an environment variable; a versioned URI pins one version. The @Microsoft.KeyVault(...) syntax belongs to App Service and Functions app settings; Container Apps would pass it to the container as a literal string.

Securing Azure Functions means choosing how callers authenticate (App Service Authentication or access keys), which network features the hosting plan allows, and how the app authenticates to its own dependencies.

Authentication: Easy Auth vs access keys

HTTP triggers have an authorization level: anonymous, function (a function key or host key) or admin (the master key). Keys are shared secrets that identify an app, not a user, and anything in a browser can be read. The master key grants admin access to the whole function app. When every request must carry an Entra token and developers won't write validation code, use App Service Authentication (Easy Auth) with the Microsoft identity provider: the platform validates the token before the request reaches the function. CORS only tells browsers which origins may call; it authenticates nothing.

Network features depend on the hosting plan

Access restrictions filter callers of the public endpoint; they never give the app a private IP. Inbound and outbound are separate: a private endpoint on the app governs traffic to it, while VNet integration gives the app an outbound path into a network. To reach a storage account whose public access is disabled, the app needs VNet integration plus DNS that resolves the account to its private endpoint, which means linking the privatelink.blob.core.windows.net private DNS zone to the integrated network. A service endpoint targets the public endpoint, which a disabled account refuses. (General Private Link design is covered in the networking lesson.)

Identity-based connections and Key Vault references

• Replace the host storage connection string with AzureWebJobsStorage__accountName (or the service URI settings) so the host connects with its managed identity, and grant a data-plane role such as Storage Blob Data Owner (plus queue or table roles if triggers need them). Storage Account Contributor is a management role with no blob data actions.
• On Consumption and Elastic Premium, the Azure Files content share setting (WEBSITE_CONTENTAZUREFILECONNECTIONSTRING) still needs a connection string, because Azure Files doesn't support identity-based connections for it.
• Key Vault references (@Microsoft.KeyVault(SecretUri=...) in an app setting) keep secret values out of configuration, but a referenced account key or SAS token is still a shared secret. Use them when a secret is unavoidable, and identity-based connections when the target supports Entra ID.

Logic Apps security controls who can start a workflow (trigger authorization and IP restrictions) and who can see the data that flows through it (run history access and secure inputs and outputs).

Request trigger authorization

• Shared access signature (SAS): the callback URL copied from the designer contains SAS query parameters (sp, sv, sig). Anyone with the URL can call. Regenerating access keys invalidates old URLs.
• OAuth with Microsoft Entra ID (Consumption): add an authorization policy with claims such as issuer and audience; callers send a bearer token. A request may use only one scheme: a call that carries both SAS parameters and a bearer token fails, so OAuth callers must use the trigger URL without the SAS parameters. To refuse SAS altogether on a Consumption workflow, disable it through sasAuthenticationPolicy under accessControl.
• Standard (single-tenant) workflows can use App Service Authentication (Easy Auth) for Request triggers, and also support private endpoints for inbound traffic and VNet integration for outbound.

IP access control: triggers vs run history

The two are independent. "Only other Logic Apps" accepts only parent workflows that call through the built-in Azure Logic Apps action; everything else is rejected, including API Management and even a logic app that uses the HTTP action. The run-history restriction hides all steps' data from callers outside the range.

Secure inputs and secure outputs

These per-step settings obscure data in run history (and in run history API responses) for one trigger or action. Secure inputs hides what the step received; secure outputs hides what it returned. Securing the outputs of a step also obscures the inputs of later actions that explicitly use them. Choose the half that matches the data you must protect: securing both when only one side is sensitive hides more of the run history than the requirement asks for, which slows troubleshooting. Neither setting changes who can start the workflow.

App Service security settings control which sources reach the app and its deployment (SCM/Kudu) site, how deployments authenticate, and which protocols browsers may use.

Access restrictions

Access restriction rules allow or deny traffic by IP range, virtual network subnet (service endpoint) or service tag, evaluated by priority. When rules exist, the unmatched rule action decides the rest, and adding the first rule of any kind makes unmatched traffic default to deny unless the unmatched rule action is set to Allow. Rules can also carry HTTP header filters, limited to X-Forwarded-For, X-Forwarded-Host, X-Azure-FDID and X-FD-HealthProbe; they can't match an arbitrary custom header.

• Locking an app to one Front Door profile: the AzureFrontDoor.Backend tag covers the addresses every customer's Front Door uses to reach origins, so add an X-Azure-FDID filter with your profile's ID to the same rule. AzureFrontDoor.Frontend is the wrong address set (what clients connect to), and X-Forwarded-Host can be set by any profile owner.
• The same reasoning applies to the ApiManagement service tag: it matches every customer's APIM instances, so it doesn't prove a call came through yours.
• Advanced tool site (SCM/Kudu): it can inherit the main site's rules or have its own. To keep the app public while limiting Kudu to build agents, give the advanced tool site its own Allow rule and don't use the main site rules. Disabling public network access or adding a private endpoint closes the whole app, not just Kudu.

Basic auth publishing credentials

Publish profiles hold a username and password. Two separate switches control them:

Deployments that authenticate with Microsoft Entra ID, such as GitHub Actions with OpenID Connect, keep working. Resetting the publish profile only rotates the credentials, and a network rule that denies the SCM site also blocks legitimate deployment through it.

HTTPS, TLS and client certificates

• HTTPS Only redirects plain HTTP requests to HTTPS.
• Minimum Inbound TLS Version rejects clients that negotiate older TLS on the site; SCM Minimum Inbound TLS Version is the separate setting for the Kudu site.
• Client certificate mode (Required, Optional, Optional interactive user) asks clients for a certificate (mutual TLS). App Service forwards the certificate to the app (in the X-ARR-ClientCert header); validating which certificate is acceptable is the app code's job.
• Access restrictions filter by source, not by port, so they can't redirect HTTP.

Azure Web Application Firewall (WAF) inspects HTTP requests against managed rule sets and your own custom rules, on Application Gateway (regional) or Azure Front Door (global edge), and its policy mode decides whether matches are blocked or only logged.

Mode and tier

• Detection mode logs matches and lets every request through; Prevention mode takes the rule action (block, for example). Detection is the usual starting mode for tuning false positives before switching to Prevention. This applies to custom rules as well as managed rules.
• Application Gateway WAF v2 supports the Microsoft Default Rule Set (DRS) or OWASP CRS, a bot protection rule set, custom rules and request body inspection settings.
• On Front Door, Standard supports custom rules (including geo-filtering and rate limiting); the Microsoft-managed rule set and bot protection need Premium. A profile can be upgraded from Standard to Premium. Application Gateway WAF policies can't be attached to Front Door.

Tuning false positives without losing coverage

• Exclusions stop managed rules inspecting a named request attribute (a header, cookie, query argument or request body field). Scope them to the one rule that misfires (per-rule exclusion) rather than the whole rule set, so other rules still inspect that field. Exclusions apply to managed rules and request attributes; they can't exempt a client IP.
• Per-site and per-URI policies (Application Gateway WAF v2): associate a separate WAF policy with a listener or a path-based rule such as /support/*. That policy replaces the global one for that path, so it should otherwise mirror the global managed rules and settings.
• Avoid broad fixes: disabling a rule globally, turning off request body inspection, or an Allow custom rule on a path all remove far more protection than the false positive needs.

Custom rules

Custom rules have a match condition (IP, geo location, request URI, headers and so on), an action (Allow, Block, Log, Redirect on Front Door) and a priority. They are evaluated before managed rules, in ascending priority number: a lower number runs first. Allow and Block stop further processing; Log records the match and continues. So an allow-list exception must have a lower priority number than the block rule it overrides, and an Allow match also skips managed rule evaluation for that request.

• Rate limit rules count requests per client over a time window and act once the threshold is crossed. Front Door Standard and Premium count by client socket IP over a one- or five-minute window; Application Gateway WAF v2 supports them too (on CRS 3.2 or later), grouping by client address, geolocation or the X-Forwarded-For header; add a match condition to target, say, a login path. Like any rule, they only block in Prevention mode.
• Geo-filtering blocks or allows by country, which also affects legitimate users in that country; it isn't a rate control. Bot protection classifies bots by signature and reputation rather than enforcing a request ceiling.

API Management protects a back end in two directions: inbound policies decide which client requests are allowed through and how many, and back-end authentication proves to the API that a call came from your APIM instance. (AI Gateway policies for model endpoints are covered in the AI security lesson.)

Inbound protection

<inbound>
  <rate-limit-by-key calls="20" renewal-period="10"
      counter-key="@(context.Request.IpAddress)" />
</inbound>

Back-end authentication

• authentication-managed-identity: APIM obtains an Entra token for its own managed identity for the resource you name and attaches it to the back-end call. Pair it with App Service Authentication on the back end, configured to accept that audience and only APIM's identity, and the API rejects calls that don't come through this instance, with no code change and no secret to store or rotate.
• authentication-certificate: APIM presents a client certificate on the TLS connection to the back end (mutual TLS). Add the certificate to APIM as a Key Vault reference read with APIM's managed identity so renewed versions are picked up automatically; an uploaded PFX must be replaced by hand. A back end that requires mutual TLS rejects a token-only call.
• Network-only approaches have limits: the ApiManagement service tag is shared by all customers' instances, and App Service header filters can't match a custom shared-secret header (which would also need rotating). Private networking between APIM and the back end is the network-layer alternative.