Azure Security Hardening: Container Apps & ACR Guide

by SD Solar 53 views

Hey guys! This article dives deep into securing your Azure Container Apps (ACAs) and Azure Container Registry (ACR), based on a recent security review. We'll cover the findings, the risks, and most importantly, the actionable steps you can take to harden your setup. Let's get started!

Understanding the Security Gaps

First off, let's look at the overview of the initial Azure infrastructure security review, which was performed for the Octopets workload in a specific subscription and resource group. The main goal here is to point out networking and registry posture gaps that are present which increase the exposure. The goal is to address them promptly. Any critical and/or high code-level findings will be addressed once the repository analysis is done. Let's break down the key findings:

Affected Resources

Here are the main resources that were analyzed:

  • Azure Container Registry (ACR): acr2tr7b4yvvvogs
  • Azure Container Apps: octopetsfe (targetPort 80), octopetsapi (targetPort 8080)
  • Managed Environment: cae-2tr7b4yvvvogs
  • User-Assigned Managed Identity: mi-2tr7b4yvvvogs

Key Findings

  1. ACR Public Network Access Enabled: The ACR has public network access enabled, and the Basic SKU is preventing the use of network rules and Private Link. This means anyone can potentially access your registry if they know the address.
  2. No VNet/Private Networking for Managed Environment: The managed environment lacks a VNet configuration. This means the environment is public by default. Network-level isolation isn't in place.
  3. External Ingress on Container Apps: Both octopetsfe and octopetsapi have external ingress enabled. This means your apps are directly accessible from the internet, increasing the attack surface. They're using a UAMI (User-Assigned Managed Identity), which is good, but without IP restrictions, it's wide open.
  4. Secrets Handling: Application Insights secrets are handled via secretRef, which is great. No plaintext secrets were detected in the Container Apps environment (except for AZURE_CLIENT_ID, which is an identifier, not a secret).

The Risks and Impact

So, what's the big deal, right? Well, let's break down the risks and the impact of these findings:

  • Increased Attack Surface: Public ACR and Container Apps mean a larger attack surface. Attackers can try recon, brute-force attacks, and token abuse.
  • Supply Chain Risk: Lack of registry controls (content trust, soft delete, retention, quarantine) increases the risk of supply chain attacks. If a malicious image gets into your registry, it could cause big problems.
  • Recovery Time: Without proper controls, recovering from an incident will take longer.
  • Network Exposure: Without private networking, there is no network-level isolation or policy enforcement.

Recommendations: Actionable Steps

Okay, now the good part! Here's what you need to do to fix these issues. We'll go through each area, with high-priority actions first.

ACR Hardening (Priority: High)

  1. Upgrade to Premium: Upgrade your ACR to the Premium tier. This enables firewall rules and Private Link, giving you much better control.
  2. Disable Public Network Access: Once you've upgraded, disable public network access. Create a Private Endpoint in a dedicated subnet to allow private access.
  3. Enable Registry Policies: Enable content trust (using Notary, if needed), soft delete, and image retention. This helps protect your images.
  4. Consider Quarantine: Consider enabling image quarantine for images that fail validation checks.

Here's an example of how to upgrade ACR via the Azure CLI:

# Upgrade to Premium
az acr update -n acr2tr7b4yvvvogs -g rg-octopets-test-devday --sku Premium
# Disable public network access
az acr update -n acr2tr7b4yvvvogs -g rg-octopets-test-devday --public-network-enabled false
# Enable soft delete and retention (example: 30 days)
az acr config retention update -n acr2tr7b4yvvvogs -g rg-octopets-test-devday --status enabled --days 30
# Enable content trust (if required by your process)
az acr config content-trust update -n acr2tr7b4yvvvogs -g rg-octopets-test-devday --status enabled

Container Apps and Environment Hardening (Priority: High)

  1. VNet Injection: Configure your Container Apps managed environment with VNet injection and internal access. This places the environment in a secured subnet, providing network isolation.
  2. Front with WAF/AF: If you need public exposure, front your apps with Azure Front Door or Azure Application Gateway (with a Web Application Firewall - WAF) and restrict direct ingress. Consider making apps internal-only where possible.
  3. Authentication and mTLS: For your API, enforce authentication and authorization at the edge. Consider using mutual TLS (mTLS) for service-to-service traffic within the environment. This means that every service verifies the identity of the other service. mTLS adds an extra layer of security and protection.

Here's an example of how to configure this using the Azure CLI:

# Create or use an existing VNet/subnet, then create a new environment with VNet
az containerapp env create -g rg-octopets-test-devday -n cae-priv --infrastructure-subnet-resource-id \
  "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Network/virtualNetworks/<vnet>/subnets/<subnet>"
# Migrate apps to the VNet-enabled environment and set internal ingress where feasible
az containerapp update -g rg-octopets-test-devday -n octopetsapi --ingress external false
az containerapp update -g rg-octopets-test-devday -n octopetsfe --ingress external false
# If external is required, add IP restrictions (example allows only WAF public IP)
az containerapp ingress access-restriction set -g rg-octopets-test-devday -n octopetsapi \
  --rule-name allow-waf --action Allow --ip-address 203.0.113.10/32

Registry/Image Supply Chain (Priority: Medium)

  1. Image Signing and Scanning: Implement image signing and verification (ACR content trust or Notary v2) and CI policies. Use SAST/DAST and dependency scanning before pushing or promoting images.
  2. Soft Delete and Retention: Enable soft delete and retention policies to reduce the risk of stale or vulnerable images. This is a very important part of the process.

Monitoring and Logging (Priority: Medium)

  1. Keep Log Analytics: Ensure you have Log Analytics integration set up. Add Defender for Cloud container registry and Container Apps plans for threat detections and just-in-time guidance. This allows you to monitor and receive alerts.

Evidence

Let's take a look at the evidence that supports these findings.

ACR

{
  "adminUserEnabled": false,
  "anonymousPullEnabled": false,
  "loginServer": "acr2tr7b4yvvvogs.azurecr.io",
  "name": "acr2tr7b4yvvvogs",
  "publicNetworkAccess": "Enabled",
  "sku": "Basic"
}

Policies

{
  "azureAdAuthenticationAsArmPolicy": {"status": "enabled"},
  "exportPolicy": {"status": "enabled"},
  "quarantinePolicy": {"status": "disabled"},
  "retentionPolicy": {"days": 7, "status": "disabled"},
  "softDeletePolicy": {"retentionDays": 7, "status": "disabled"},
  "trustPolicy": {"status": "disabled", "type": "Notary"}
}

Private Endpoints

[]

Container Apps Ingress (octopetsfe)

{
  "external": true,
  "allowInsecure": false,
  "transport": "Http",
  "targetPort": 80,
  "fqdn": "octopetsfe.graymoss-db3028c7.eastus2.azurecontainerapps.io"
}

Container Apps Ingress (octopetsapi)

{
  "external": true,
  "allowInsecure": false,
  "transport": "Http",
  "targetPort": 8080,
  "fqdn": "octopetsapi.graymoss-db3028c7.eastus2.azurecontainerapps.io"
}

Compliance Mapping

These recommendations align with industry best practices and compliance standards:

  • OWASP Top 10: Specifically, we're addressing A05:2021 – Security Misconfiguration and A07:2021 – Identification and Authentication Failures (edge auth hardening).
  • Azure Security Benchmark: We're hitting NS-1/2 (Network segmentation/Private access), PV-1 (Secure registry), LT-2 (Logging), and IM-1/2 (Managed identity usage).

IaC and APIM Check

  • No IaC Files: No Infrastructure as Code files were detected. This means no Bicep, JSON ARM, Terraform, or YAML files. No APIM resources were found either.

Next Steps

The next steps involve deciding on a scope and a timeline for the following:

  1. Upgrade ACR to Premium and disable public network access with Private Link.
  2. Deploy a VNet-enabled Container Apps environment and restrict ingress.
  3. Enable registry policies (soft delete, retention, content trust).
  4. Front public endpoints with WAF and IP restrictions.

I will file separate issues for any critical and/or high code-level findings after the code security review completes. This will ensure that we address the root causes of the vulnerabilities and prevent future occurrences.

This issue was created by security-test--5dec778a Tracked by the SRE agent here