Securing ArgoCD with AWS IAM Identity Center via Dex SAML
Integrating ArgoCD with AWS IAM Identity Center (AWS IdC) for Single Sign-On (SSO) offers a robust and centralized approach to managing access. This method leverages ArgoCD's bundled Dex as a SAML service provider, effectively using your AWS IdC as the identity provider. The primary advantage is consolidating ArgoCD access management within AWS IdC, treating it like any other AWS resource. This simplifies onboarding and offboarding users, ensuring that access to your CI/CD platform is governed by your organization's central identity policies.
A key benefit of this SAML-based integration is the elimination of client secrets. The trust between AWS IdC and Dex is established using certificates. AWS IdC's public signing certificate is used to verify SAML assertions, meaning there's no sensitive secret to store or rotate within your ArgoCD or Dex configuration. Furthermore, this architecture avoids requiring cluster egress for authentication. The SAML flow is entirely browser-mediated. Dex verifies the assertion using the embedded certificate, negating the need for outbound calls from your cluster to the identity provider.
Understanding the SAML Flow
The process begins when a user attempts to access ArgoCD. ArgoCD, configured to use Dex for authentication, redirects the user to Dex. Dex, acting as the SAML Service Provider (SP), then initiates a SAML authentication request to AWS IAM Identity Center, which acts as the SAML Identity Provider (IdP). The user authenticates directly with AWS IdC. Upon successful authentication, AWS IdC generates a SAML assertion containing user identity information and signs it with its private key. This signed assertion is then sent back to the user's browser, which relays it to Dex. Dex receives the assertion, verifies its signature using AWS IdC's public signing certificate (which is pre-configured in Dex), and if valid, issues its own session token to the user. This token allows the user to access ArgoCD.
Configuration Steps
To implement this integration, several configuration steps are necessary on both ArgoCD and AWS IAM Identity Center.
ArgoCD Configuration (Dex as SAML SP)
ArgoCD bundles Dex, making it convenient to set up. You'll need to configure Dex to act as a SAML SP. This involves defining a SAML connector within Dex's configuration. The critical parameters include:
- ID: A unique identifier for this connector (e.g.,
aws-iam-identity-center). - Name: A human-readable name (e.g.,
AWS IAM Identity Center). - Type: Set to
saml. - Config: This section contains the SAML-specific settings:
- EntityID: The unique identifier for your Dex SAML SP. This should match what AWS IdC expects. Often, this is the URL of your ArgoCD instance (e.g.,
https://argocd.example.com). - SSO URL: The SAML Single Sign-On endpoint provided by AWS IAM Identity Center.
- Signing Certificate: The public certificate of AWS IAM Identity Center. This is crucial for Dex to verify the authenticity of the SAML assertions sent by AWS IdC.
- Username attribute: The claim within the SAML assertion that Dex should use as the username.
- Groups attribute: The claim for group memberships, if applicable.
- Redirect URL: The URL where AWS IdC should send the SAML assertion after successful authentication. This is typically Dex's SAML callback URL.
These configurations are typically applied by modifying the ArgoCD Custom Resource Definition (CRD) or through its CLI. Ensure ArgoCD is accessible via HTTPS at a stable hostname, as this is a prerequisite for SAML communication.
AWS IAM Identity Center Configuration (as SAML IdP)
On the AWS side, you need to configure AWS IAM Identity Center to trust Dex as a Service Provider. This involves:
- Creating a SAML Application: Within AWS IAM Identity Center, you'll create a new SAML application.
- Configuring SP Details: You will provide the EntityID of your Dex SP and the Assertion Consumer Service (ACS) URL (the Redirect URL mentioned above).
- Attribute Mappings: Define which user attributes from your identity source (AWS directory, AD, Google Workspace, etc.) should be included in the SAML assertion. Essential attributes include username, email, and potentially group memberships for role-based access control in ArgoCD.
- Downloading IdC Metadata/Certificate: AWS IdC will provide metadata or a direct download of its public signing certificate. This certificate is what you'll provide to Dex.
It's important to note that AWS IAM Identity Center can use various identity sources, including its own AWS Directory Service, Active Directory, or external identity providers like Google Workspace or Azure AD. The SAML integration with ArgoCD works regardless of the underlying identity source configured in AWS IdC.
Handling Gotchas and Best Practices
Several non-obvious issues can arise during this setup. One common pitfall is the mismatch between the EntityID configured in Dex and what AWS IdC expects. Ensure these values are identical. Another critical point is the correct configuration of the Assertion Consumer Service (ACS) URL. This must precisely match the callback endpoint for Dex's SAML integration. If your ArgoCD instance is behind a load balancer or ingress controller, ensure the hostname used in the SAML configuration is the publicly accessible one and that HTTPS is properly terminated.
The signing certificate from AWS IdC must be correctly imported into Dex. Any expiry or changes to this certificate will break the trust relationship, requiring an update in Dex. For role-based access control within ArgoCD, you'll need to map SAML group attributes from AWS IdC to ArgoCD's RBAC roles. This involves defining which groups in AWS IdC correspond to specific permissions within ArgoCD, such as read-only access, project administration, or cluster management.
Finally, always test the SSO integration thoroughly with a test user before rolling it out to your entire team. Verify that logins work as expected and that user permissions are correctly applied according to their group memberships. The surprising detail here is how seamlessly this integrates with existing AWS IdC setups, even those using external identity sources, without requiring complex network configurations or secret management.