How do you set up Service Connections to securely deploy to AWS or Kubernetes from Azure DevOps?
Quick Answer
Service Connections in Azure DevOps securely store credentials for external services like AWS, Kubernetes, or Docker registries. They use workload identity federation or service principals to authenticate without storing long-lived secrets, apply RBAC controls to limit which pipelines can use them, and provide audit trails showing which deployments used which credentials.
Detailed Answer
Think of Service Connections like the security badge system in a corporate building. Instead of giving every employee a master key to every room, each person receives a badge programmed with access to only the floors and rooms their job requires. The badge system logs every door opened, when, and by whom. If an employee leaves, their badge is deactivated immediately without affecting anyone else. Service Connections work the same way: they grant specific pipelines access to specific external resources using scoped credentials, log every usage, and can be revoked without disrupting other workflows.
A Service Connection is a secure object in Azure DevOps that stores authentication information for an external service. When a pipeline task needs to push a Docker image to ECR, deploy to a Kubernetes cluster, or provision AWS infrastructure with Terraform, it references a Service Connection by name rather than embedding credentials directly in the pipeline YAML. The Service Connection encapsulates the authentication mechanism: an AWS access key and secret key for AWS connections, a kubeconfig or service account token for Kubernetes, or a service principal for Azure. This separation means credentials are managed centrally by administrators and never exposed to pipeline authors or visible in YAML files.
For AWS connections, Azure DevOps supports two approaches. The basic approach stores an AWS IAM access key and secret key directly in the Service Connection. The preferred approach for production uses OIDC federation, where Azure DevOps authenticates to AWS using a federated identity token rather than static credentials. With OIDC federation, you configure an identity provider in AWS IAM that trusts Azure DevOps, create an IAM role with specific permissions, and configure the Service Connection to assume that role using OIDC. No static credentials are stored anywhere, eliminating the risk of leaked access keys. The IAM role's trust policy restricts which Azure DevOps organization and project can assume it, preventing unauthorized use.
For Kubernetes connections, you can authenticate using a kubeconfig file, a service account token, or Azure Kubernetes Service connections that leverage Azure Active Directory integration. The recommended approach for AKS clusters is the Azure Resource Manager connection type, which uses Azure AD workload identity to authenticate. For non-Azure Kubernetes clusters like EKS or self-managed clusters, you create a Kubernetes service account with RBAC permissions scoped to specific namespaces, generate a long-lived token, and store it in the Service Connection. The service account should have only the permissions needed for deployment, not cluster-admin, following the principle of least privilege.
Service Connection security is enforced through pipeline permissions and approvals. Administrators can restrict which pipelines are authorized to use a Service Connection, requiring explicit approval before new pipelines gain access. Project-level Service Connections are visible only within their project, while organization-level connections can be shared across projects. Approval checks can require a human to authorize before any pipeline uses a production Service Connection, adding a governance layer beyond pipeline-level approvals.
The production gotcha is credential rotation and monitoring. Static credentials in Service Connections must be rotated regularly, and many organizations forget to automate this rotation. When an AWS access key is rotated in IAM without updating the Service Connection, all pipelines using it fail simultaneously. OIDC federation eliminates this problem for AWS and Azure connections. For Kubernetes service account tokens, teams must monitor expiration and automate renewal. Another common mistake is granting Service Connections broad permissions: an AWS IAM role with AdministratorAccess or a Kubernetes service account with cluster-admin violates least privilege and creates excessive blast radius if the connection is compromised.