Containers

Accessing private Git repositories from Amazon EKS capability for Argo CD

Organizations adopting GitOps on Amazon Elastic Kubernetes Service (Amazon EKS) often need to pull application manifests from private Git repositories that are not publicly accessible. Amazon EKS capability for Argo CD (referred to as ‘Argo CD capability’ throughout this post) can access publicly hosted Git repositories using Argo CD repository secrets. However, connecting Argo CD capability to private Git repositories presents challenges, because the capability cannot directly access repositories that are not publicly accessible. The Argo CD capability doesn’t have direct access to the customer’s Amazon Virtual Private Cloud (VPC) network, so it can’t reach privately hosted Git servers. When you want to securely connect Argo CD capability to private repositories within your VPC, AWS CodeConnections provides authentication based on AWS Identity and Access Management (IAM) while maintaining your security posture.

In this post, we walk you through three main steps: First, you create an AWS CodeConnections host in your VPC with connectivity to your private Git server. Second, you establish a connection that Argo CD can use. Finally, you deploy a sample application to verify the integration. By the end, you have a secure way to deploy applications from private repositories.

Architecture overview

The architecture diagram illustrates a secure GitOps workflow in which an Amazon EKS cluster with Argo CD capability accesses private Git repositories through AWS CodeConnections. An AWS CodeConnection is created in a VPC which has private network connectivity to an on-premises data center where a private Git server is hosted. Argo CD capability uses an IAM role to access the connection, and then pulls the latest configurations and synchronizes them to an EKS cluster. This integration deploys or updates applications to the EKS cluster while maintaining an enhanced security posture throughout the pipeline.

Architecture for configuring AWS CodeConnections to access Private Git Servers

Figure 1

Solution walkthrough

Start by creating the AWS CodeConnections host in a VPC that acts as a git-proxy for accessing your private repository. For private repositories, AWS CodeConnections currently supports GitHub Enterprise Server and self-managed GitLab. This walkthrough uses GitHub Enterprise Server, but the configuration is analogous for GitLab self-managed servers.

Prerequisites

Before you begin, verify that you have:

  • An AWS account with permissions to create CodeConnections and VPC resources.
  • An Amazon EKS cluster with Argo CD capability enabled.
  • AWS Command Line Interface (AWS CLI) version 2.x or later installed and configured.
  • kubectl configured to access your EKS cluster.
  • A private Git server (GitHub Enterprise Server or GitLab self-managed) accessible from your VPC.
  • Admin permissions to install the GitHub App.

Connect private Git server with AWS CodeConnections

To connect your private Git server with AWS CodeConnections, follow these steps:

  1. Set the environment variables required for the setup.
    export GIT_ENDPOINT_URL="https://github.example.com"  # Private Git Server URL
    export REGION="us-west-2"
    export VPC_ID="vpc-0c0a64adaa55b2dde"  # VPC ID where the Host will be created
    export SUBNET_IDS="subnet-0099c63c1499e95c6,subnet-0849c92d198b5ff9b"
    export SECURITY_GROUP_ID="sg-08e49afc4f10e1792"

    Verify the subnets meet the following requirements:

    • Route table entries that allow traffic to your Git server (either through a VPN, Direct Connect, or Transit Gateway for on-premises servers).
    • Domain Name System (DNS) resolution configured if using domain names (enable DNS hostnames and DNS resolution on your VPC).
    • Security group rules allowing outbound HTTPS (port 443) traffic to your Git server.
    • Each subnet in a different Availability Zone for high availability (HA).
  2. Create the host VPC configuration file:
    # CA certificate is Optional for the Git endpoint URL
    cat << EOF > vpc-config.json
    {
        "VpcId": "$VPC_ID",
        "SubnetIds": [$(echo $SUBNET_IDS | sed 's/,/", "/g' | sed 's/^/"/' | sed 's/$/"/')],
        "SecurityGroupIds": ["$SECURITY_GROUP_ID"],
        "TlsCertificate": "-----BEGIN CERTIFICATE-----\nMIIDUTCCAjmgAwIBAgIUYj96GhoT7XDJJbeC\n-----END CERTIFICATE-----"
    }
    EOF

    Note: Include the ‘TlsCertificate’ field only if your Git server uses a privately signed certificate. If your server uses a publicly trusted certificate, you can omit this field.

  3. Create the host and capture the HostArn with the following command.
    export HOST_ARN=$(aws codeconnections create-host \
      --name "github-" \
      --provider-type GitHubEnterpriseServer \
      --provider-endpoint "$GIT_ENDPOINT_URL" \
      --vpc-configuration file://vpc-config.json \
      --region "$REGION" \
      --query 'HostArn' --output text)
  4. Navigate to the host dashboard on the AWS Management Console. Wait for the host to reach Pending status.Host dashboard on the AWS Management Console showing the created host in Pending statusFigure 2After the host is in the Pending state, select the host and choose Set up host. The page notifies you about redirection to the Git endpoint. Here, choose Continue. For GitLab, enter the personal access token and then choose Continue.

    CodeConnections host setup page prompting to continue to the Git endpoint

    Figure 3

    GitHub Enterprise Server host setup confirmation in the AWS Management Console

    Figure 4

  5. Complete the guided host setup after redirection. If an issue occurs, follow the steps in the AWS CodeConnections troubleshooting guide. After successful setup, the host shows the Available status, and you can revoke or delete the personal access token for GitLab.Host dashboard showing the host in Available statusFigure 5
  6. Create a connection to use with the Argo CD capability.
    aws codeconnections create-connection \
      --connection-name github --host-arn $HOST_ARN \
      --region $REGION
  7. Navigate to the Connections dashboard on the console and select the connection created earlier. The status of the connection should show Pending.Connections dashboard showing the new connection in Pending statusFigure 6
  8. Select the connection and choose Update pending connection. The console redirects you to the Git server. Follow the guided steps to continue.Update pending connection redirecting to the Git serverFigure 7Git server authorization page for the AWS Connector app

    Figure 8

    After the authorization step, the page redirects to the console.

    Redirect back to the AWS Management Console after Git server authorization

    Figure 9

  9. Choose Continue to complete the connection setup. For GitHub, the page redirects again to GitHub for installing the app for a particular user or organization. Follow the steps and configure the GitHub App.GitHub App installation page for selecting a user or organizationFigure 10

With this, the connection status should change to Available. Now you can use this connection with Argo CD capability and deploy the application to the EKS cluster.

Create a sample Argo CD application

Before moving forward, verify that the Argo CD configurations such as the Cluster Secret and AppProject roles are added to the cluster, as shown in the AWS blog post Deep dive: Streamlining GitOps with Amazon EKS capability for Argo CD.

Argo CD cluster secret and AppProject roles configured on the EKS cluster

Figure 11

You will use the Argo CD sample guestbook application, which is pushed to your private Git server. You can also use your existing application, or clone this repository and push it to the private Git server for which you created the connection in the previous section.

Create a file guestbook.yaml and paste the following content into it. Replace the placeholders with values applicable to you.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://codeconnections.<CodeConnection_Region>.amazonaws.com/git-http/<Your_Account_ID>/<CodeConnection_Region>/<Connection_ID>/<Git_Username/Git_Organization/Project>/<Git_Repository>.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: arn:aws:eks:<EKS_Cluster_Region>:<Account_ID>:cluster/<Target_EKS_Cluster_Name>
    namespace: guestbook

Note: The repoURL follows the CodeConnections Git HTTP proxy format. Replace the placeholders with your actual values:

  • <CodeConnection_Region> – The AWS Region where your CodeConnection was created (for example, us-west-2).
  • <Your_Account_ID> – Your 12-digit AWS account ID.
  • <Connection_ID> – The unique identifier of the CodeConnection you created in Step 6. You can retrieve it from the connection Amazon Resource Name (ARN) (the segment after connection/), or find it in the console under Developer Tools > Settings > Connections.
  • <Git_Username/Git_Organization/Project> – The owner or organization name on your Git server that contains the repository.
  • <Git_Repository> – The name of the repository you want Argo CD to sync from.

Apply this manifest to the EKS cluster where Argo CD capability is enabled.

kubectl apply -f guestbook.yaml

Navigate to the Argo CD endpoint URL and monitor the application until it reaches the Healthy status.

Under the hood

Understanding how CodeConnections works behind the scenes can help you troubleshoot issues and design your network security. Here’s what happens when you create an AWS CodeConnections host in a VPC. It creates a cross-account elastic network interface (ENI) in each provided subnet and attaches the provided security group to it. These ENIs connect with the private Git server endpoint that you specified during host creation. This gives AWS CodeConnections a private and secure network path while interacting with the Git server.

Creating the connection using this host installs the AWS Connector app on the repository, organization, or project. This app gets temporary credentials for each interaction between AWS CodeConnections and private Git servers.

Argo CD capability uses IAM authentication with an associated IAM role to access the specified connection in the application manifest. The network path looks like the following:

Network path from Argo CD capability through AWS CodeConnections to the private Git server

Figure 12

Clean up

To avoid incurring future charges, delete the resources you created:

  1. Delete the Argo CD application:
    kubectl delete -f guestbook.yaml
  2. Delete the AWS CodeConnection:
    aws codeconnections delete-connection --connection-arn <CONNECTION_ARN>
  3. Delete the CodeConnection host:
    aws codeconnections delete-host --host-arn $HOST_ARN
  4. If you created an EKS cluster specifically for this tutorial, delete the EKS cluster and associated resources.

Conclusion

In this post, we showed you how to securely connect private Git servers to the Amazon EKS capability for Argo CD using AWS CodeConnections. You created an AWS CodeConnections host in your VPC, established a connection to your private Git server, and deployed a sample application without managing long-term credentials.

Using AWS CodeConnections to access repositories hosted on private Git servers from Argo CD capability provides multiple benefits. With this setup, you can:

  • Connect to fully private Git servers over private networking.
  • Use Cross-Region AWS CodeConnections with Argo CD capability, which makes integration with private repositories easier.
  • Control access to the private Git server by allowlisting IP addresses from the VPC Classless Inter-Domain Routing (CIDR) block.
  • Avoid repository configuration for Argo CD capability when using AWS CodeConnections.
  • Avoid configuring long-term credentials or permissions for the AWS Connector application on the Git server.

To learn more, check out Create an Argo CD capability, Working with AWS CodeConnections hosts, Working with AWS CodeConnections, and Configure repository access with AWS CodeConnections.


About the authors

Carlos Santana

Carlos Santana

Carlos is a Senior Worldwide Specialist Solutions Architect at AWS, where he focuses on cloud-native technologies, Kubernetes, and AI/ML systems. As a CNCF Ambassador, he bridges AWS-specific solutions with the broader open-source ecosystem, specializing in Amazon EKS, container orchestration, and emerging technologies like the Model Context Protocol (MCP) and Agentic AI systems.

Pankaj Walke

Pankaj Walke

Pankaj is a Senior Open Source Engineer at AWS. He works for Cloud Native Operational Excellence (CNOE) initiative with a focus on Platform Engineering on Kubernetes and CNCF technologies.