Skip to content

Requirements

Operational Requirements

Network

The ansible endpoint must be able to reach all linux hosts in all accounts/subscriptions on port 22 and all windows hosts in all accounts/subscriptions on port 5985 and 5986.

If ansible is deployed as a container, be sure that the source used for network rules takes into consideration that the container may be restarted and assigned a different IP address. See cloud specific container deployment documentation below. If ansible is deployed on a VM, the network rules can be configured to allow the VM's IP address as the source for the traffic.

Deployment Requirements

AWS Container

  • EFS filesystem, EFS access point, EFS mount targets in the subnet(s) the Ansible container is deployed to and the ability to resolve the EFS endpoint.
  • The Ansible container subnet may be colocated on the sharedinfra subnet or in a dedicated subnet for the Ansible container.
  • Routes from the Ansible container subnet(s) to all subnets with machines that will be managed by Ansible.
  • IAM role with "ec2:DescribeInstances" and "sts:AssumeRole" to assume roles in other accounts with the "ec2:DescribeInstances" role.
  • If using the GitHub Actions runner with GITHUB_RUNNER_PAT, the ECS task execution role must also have secretsmanager:GetSecretValue on the secret ARN storing the PAT. The secret must be stored as a plain string, not a JSON object. See Automated Deployment.
  • If fetching the vault password or the SSH private key from AWS Secrets Manager (see Secret Management), the ECS task role — not the execution role — must have secretsmanager:GetSecretValue on each relevant secret ARN. This is the role the running container actually assumes at runtime, confirmable via aws sts get-caller-identity inside the container; it's the opposite of the GITHUB_RUNNER_PAT requirement above, which needs the execution role instead because ECS injects that secret before the container starts, rather than the container fetching it itself.
  • Optionally create a log group for the container to write logs to. This is required when connecting with a VS Code tunnel.
  • An Ansible security group allowing port 22 to the Ansible VM. The security group assigned to the ansible "service definition" will also be used as the "referenced security group" in security group rules to allow the Ansible container to reach Windows VMs on 5985 and 5986 and Linux VMs on port 22.
  • Ansible container, including: ECS cluster, ECS task definition, and ECS service.
  • The Ansible container must be able to resolve the EFS endpoint.
  • The subnet the Ansible container is deployed in must be able to reach Amazon ECR — the image is pulled through the ECR pull-through cache, which fetches from ghcr.io on ECR's side, so the subnet itself no longer needs ghcr.io egress for the image pull. The ECS task execution role needs the standard ECR pull permissions plus ecr:BatchImportUpstreamImage and ecr:CreateRepository on the ghcr/* repositories.
  • If using the GitHub Actions runner with GITHUB_RUNNER_PAT, the container subnet must be able to reach the GitHub API (api.github.com) to generate and remove runner tokens at startup and shutdown.

Azure Container

The bullets below are the summary; the full picture — exact storage account settings, identity grants vs deployer permissions, and a post-deploy validation sequence — is on the Azure Container page.

  • An ansible-files share for persistent storage on a dedicated Premium FileStorage storage account in the same region as the container — not a general-purpose or Standard account (Standard file shares have caused real performance problems for this workload), and not shared with Terraform state. Exact create-time settings: Azure Container → Persistent storage.
  • Container subnet with the "Microsoft.ContainerInstance/containerGroups" service delegation and the Microsoft.Storage service endpoint (required for the ACI file-share mount). The delegation is exclusive, so private endpoints (file, and vault if network-restricted) need a second, non-delegated subnet.
  • NSG rule allowing the container subnet to reach Windows VMs on 5985 and 5986 and Linux VMs on 22. Because the subnet is delegated specifically for container instances, this limits the scope of the rule to only apply to the Ansible container and not other resources that may be in the same VNet.
  • User assigned identity associated with the Ansible container and read privileges on the subscription(s).
  • If fetching the vault password or the SSH private key from Azure Key Vault (see Secret Management), the user assigned identity needs get permission on each relevant secret — via a classic Key Vault access policy or an Azure RBAC role assignment (Key Vault Secrets User), depending on the vault's authorization model.
  • Container with persistent storage mounted at /home/ansible/source, TCP port 22 exposed, and the user assigned identity attached.
  • The subnet the Ansible container is deployed in must be able to reach Azure Container Registry — the image is pulled through the ACR artifact cache, which fetches from ghcr.io on ACR's side, so the subnet itself no longer needs ghcr.io egress for the image pull. The user assigned identity needs the AcrPull role on the registry.
  • If using the GitHub Actions runner with GITHUB_RUNNER_PAT, the container subnet must be able to reach the GitHub API (api.github.com) to generate and remove runner tokens at startup and shutdown.