Az - Container Instances

Reading time: 5 minutes

Basic Information

Azure Container Instances (ACI) is a serverless container service that lets you run individual containers quickly without managing any underlying infrastructure. Azure Container Apps (ACA) extends this by offering a fully managed environment for running microservices and web apps with features like event-driven autoscaling, built-in Dapr integration, and support for complex orchestration scenarios. Container App Jobs are a specialized feature within ACA designed for running short-lived, batch, or scheduled tasks that execute for a finite period and then exit.

Differences:

• ACI is ideal for simple, standalone container workloads where minimal orchestration is needed.
• ACA is best suited for building scalable, interconnected microservices with advanced features like autoscaling and service discovery.
• Container App Jobs focus on one-off or scheduled tasks, providing a streamlined way to run background or batch jobs within the ACA environment.

Configurations

Special options for ACI:

• Regarding networking it's possible to select one of these 3 options:
  • Public (default)
  • Private (only accessible from the VNet)
  • None (no network access)

Special options for ACA:

• It's possible to restrict the trafic to the container to the container app environment or leave it public.
• It’s possible to use an external identity provider (Microsoft, Facebook, Google, and Twitter) for authentication
• It's possible to store App secrets (in clear text the app or as links to a vault assigning a MI with access over it)
• It’s possible to have revisions and replicas of the app
• It's possible to deploy from a specific source code or artifact instead of using a container. For the source code, access to Gihub must be given. For artifacts, it's possible to upload it after creating the app.

Special options for jobs:

• The trigger type can be manual, scheduled or event-based (like a message arriving in a queue).

Common options:

• In order to create a container it's possible to use a public image, a container image from an Azure Container Registry or an external repository, which might require to configure a password to access it.
  • This means that the configuration of the container might contain sensitive information.
• It's also possible to configure common docker settings like:
  • Environment variables (check for sensitive information)
  • Volumes (even from Azure Files)
  • Ports to expose
  • CPU and memory limits
  • Restart policy
  • Run as privileged
  • Overwrite containers command line to run and arguments (can be modified in existing containers also)
  • ...

Enumeration

# ACI
## List all container instances in the subscription
az container list

## Show detailed information about a specific container instance
az container show --name <container-name> --resource-group <res-group>

## Fetch logs from a container
az container logs --name <container-name> --resource-group <res-group>

## Execute a command in a running container and get the output
az container exec --name <container-name> --resource-group <res-group> --exec-command "/bin/sh" # Get a shell

## Get yaml configuration of the container group
az container export  --name <container-name> --resource-group <res-group> --file </path/local/file.yml>

# ACA
## List all container apps in the subscription
az containerapp list

## Show detailed information about a specific container app
az containerapp show --name <app-name> --resource-group <res-group>

## List app environments
az containerapp env list --resource-group <res-group>

## Fetch logs from a container app
az containerapp logs show --name <app-name> --resource-group <res-group>

## Get configured secrets
az containerapp secret list --name <app-name> --resource-group <res-group>
### Get value
az containerapp secret show --name <app-name> --resource-group <res-group> --secret-name <secret-name>

## Get authentication options
az containerapp auth  show --name <app-name> --resource-group <res-group>

## Get a shell
az containerapp exec --name <app-name> --resource-group <res-group> --command "sh"

## Get debugging shell
az containerapp debug --name <app-name> --resource-group <res-group>

# Jobs
## List all container apps jobs in a resource group
az containerapp job list --resource-group <res-group>

## Show detailed information about a specific container app job
az containerapp job show --name <job-name> --resource-group <res-group>

## Fetch logs from a container app job
az containerapp job logs show --name <job-name> --resource-group <res-group>

## Fetch executions from a container app job
az containerapp job execution list --name <job-name> --resource-group <res-group>
az containerapp job execution show --name <job-name> --resource-group <res-group> --job-execution-name <job-execution>

## Start a job execution (for manual jobs)
az containerapp job start --name <job-name> --resource-group <res-group>

Privilege Escalation & Post Exploitation

Az - Container Instances, Apps & Jobs Privesc