Connecting Git Repositories to ArgoCD: Enterprise-Grade Configuration and Security Hardening

Table of Contents

• 1. Introduction to Git Connections in ArgoCD
• 2. What You Will Learn
• 3. Prerequisites
• 4. Architecture and Internal Workflows
• 5. Authentication Mechanisms Compared
• 6. Declarative Configuration (The GitOps Way)
• 7. Imperative Configuration (CLI and UI)
• 8. Enterprise Credential Templates
• 9. Self-Hosted Git & Custom CA Certificates
• 10. Multi-Tenancy & Repository Access Control
• 11. Scaling Git Operations & Performance Tuning
• 12. Troubleshooting & Debugging
• 13. Monitoring & Observability
• 14. Technical Interview Questions & Answers
• 15. Frequently Asked Questions (FAQs)
• 16. Summary & Next Steps

1. Introduction to Git Connections in ArgoCD

In a true GitOps paradigm, the Git repository is the absolute source of truth for your infrastructure and application state. ArgoCD, acting as the continuous delivery engine inside your Kubernetes clusters, must continuously monitor these repositories, detect drift, and reconcile differences.

However, establishing this connection is not as simple as pointing ArgoCD to a public URL. In enterprise environments, repositories are private, protected by strict firewalls, subject to API rate limits, and governed by strict identity and access management (IAM) policies.

Featured Snippet / Definition:
An ArgoCD Git Repository Connection is a secure authentication channel configured between the ArgoCD argocd-repo-server component and a Git provider (such as GitHub, GitLab, Bitbucket, or Azure DevOps). This connection is defined declaratively using Kubernetes Secret manifests with specific labels, enabling ArgoCD to read manifest files (YAML, Helm charts, Kustomize overlays) securely using SSH, HTTPS Personal Access Tokens, or GitHub Apps without exposing credentials to the application workloads.

If your Git connections are poorly designed, your deployment pipeline can suffer from critical vulnerabilities, credential leaks, slow synchronization cycles, and API rate-limiting issues that can block hotfixes during production outages. This guide teaches you how to design, deploy, and maintain production-grade Git connections in ArgoCD.

2. What You Will Learn

• The internal mechanics of how argocd-repo-server clones, caches, and parses Git repositories.
• Deep-dive comparisons of SSH, HTTPS, and GitHub App authentication methods.
• How to write secure, declarative Kubernetes manifests to register repositories automatically.
• How to leverage Wildcard Credential Templates to manage credentials across thousands of repositories.
• Strategies for handling self-hosted Git providers with custom, enterprise PKI and private CA certificates.
• How to scale Git operations, implement webhooks to bypass polling delays, and avoid API rate limits.
• Comprehensive troubleshooting workflows for resolving authentication, SSH host key verification, and network timeout issues.

3. Prerequisites

To follow the advanced hands-on sections of this guide, you should have:

• An operational Kubernetes cluster (v1.24 or later) with administrative access.
• ArgoCD installed in your cluster (preferably in the argocd namespace). If you haven't installed it yet, refer to our ArgoCD Architecture and Installation Guide.
• A private repository hosted on GitHub, GitLab, Bitbucket, or a self-hosted instance.
• Basic familiarity with Kubernetes secrets, custom resource definitions (CRDs), and YAML syntax.
• The kubectl and argocd CLI tools installed on your local workstation.

4. Architecture and Internal Workflows

Understanding how ArgoCD interacts with your Git provider is crucial for optimizing performance and debugging connection failures. The architecture relies heavily on the argocd-repo-server component.

+---------------------------------------------------------------------------------+
|                                ArgoCD Control Plane                             |
|                                                                                 |
|  +------------------------+                        +-------------------------+  |
|  |       API Server       |                        |  Application Controller |  |
|  |    (argocd-server)     |                        |                         |  |
|  +-----------+------------+                        +------------+------------+  |
|              |                                                  |               |
|              | Requests Manifest Generation                     | Polls Git State|
|              +------------------------+  +----------------------+               |
|                                       |  |                                      |
|                                       v  v                                      |
|                        +------------------------------+                         |
|                        |      argocd-repo-server      |                         |
|                        |                              |                         |
|                        |  - Local Git Cache (/shared) |                         |
|                        |  - Manifest Generators       |                         |
|                        +--------------+---------------+                         |
+---------------------------------------|-----------------------------------------+
                                        |
                         Secure Network | HTTPS / SSH / GitHub App Auth
                         Tunnel (Egress)| (TCP Port 443 / 22)
                                        v
+---------------------------------------------------------------------------------+
|                                 Git Provider                                    |
|              (GitHub Enterprise, GitLab, Bitbucket, Azure DevOps)               |
+---------------------------------------------------------------------------------+
    

The Step-by-Step Git Operations Lifecycle

1. Trigger: The argocd-application-controller detects that a polling interval (default: 3 minutes) has elapsed, or receives an external Webhook payload indicating a new commit has been pushed to the repository.
2. Credential Retrieval: The argocd-repo-server queries the Kubernetes API for any Secret labeled with argocd.argoproj.io/secret-type: repository that matches the repository URL pattern.
3. Cloning/Fetching:
   • If the repository is being accessed for the first time, argocd-repo-server performs a full clone of the repository into its local ephemeral storage directory (typically under /tmp or /shared).
   • If the repository is already cached, it executes a git fetch to retrieve only the latest changes, optimizing network bandwidth and disk I/O.
4. Manifest Generation: Once the repository is updated locally, the argocd-repo-server executes the appropriate rendering tool (e.g., Helm, Kustomize, Jsonnet, or raw YAML parser) to generate standard Kubernetes manifests.
5. Caching: The generated manifests are cached in Redis to minimize git operations on subsequent reconciliation loops.

Because argocd-repo-server caches Git data locally, local storage speed and network latency between your Kubernetes cluster and your Git provider directly impact the overall sync performance of your GitOps pipeline.

5. Authentication Mechanisms Compared

ArgoCD supports three primary methods for authenticating against private Git repositories. Choosing the correct authentication mechanism is vital for enterprise security compliance and reliability.

6. Declarative Configuration (The GitOps Way)

To remain true to GitOps principles, you should never configure Git connections manually via the ArgoCD UI. Instead, define them as declarative Kubernetes Secret manifests. ArgoCD automatically detects these secrets by watching for specific labels.

Required Metadata Labels

For ArgoCD to recognize a Secret as a Git repository configuration, it must contain the following label:

argocd.argoproj.io/secret-type: repository

Method A: SSH Authentication (Production-Standard)

This is the most common and robust approach for GitLab, Bitbucket, and multi-tenant setups. You will generate an SSH keypair, add the public key as a deploy key in your Git provider, and provide the private key to ArgoCD.

Step 1: Generate a secure SSH Key

Use Ed25519 for optimal security and performance:

ssh-keygen -t ed25519 -C "argocd-deploy-key" -f ./id_ed25519 -N ""

Add the contents of id_ed25519.pub as a Deploy Key (Read-Only) in your Git repository settings.

Step 2: Create the Declarative Manifest

Save the following YAML as argocd-repo-ssh-secret.yaml. Ensure you replace the placeholder values with your base64-encoded credentials or use a secret operator to inject them.

apiVersion: v1
kind: Secret
metadata:
  name: enterprise-git-repo-ssh
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
  annotations:
    # Optional: Associate this repository with a specific ArgoCD project
    argocd.argoproj.io/project: default
type: Opaque
stringData:
  # The exact SSH URL of your repository
  url: git@github.com:enterprise-org/infrastructure-manifests.git
  
  # The type of connection
  type: git
  
  # The private SSH key generated in Step 1
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
    ZDI1NTE5AAAAINbO7qfX9X7Fp0mDJC6p+mU6rL/VpXh1Y2g7K9Hj9J7XAAAAiKj8Ynmo/G
    ... [Truncated for brevity - Insert your full private key here] ...
    -----END OPENSSH PRIVATE KEY-----

  # Optional: For security, enforce SSH Host Key Verification
  # Run 'ssh-keyscan github.com' to get the public host key
  insecure: "false"
  enableLFS: "true"

Method B: HTTPS with Personal Access Token (PAT)

If your organization blocks outbound SSH (TCP Port 22) or mandates HTTPS communication, use a Personal Access Token.

apiVersion: v1
kind: Secret
metadata:
  name: enterprise-git-repo-https
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
  # The HTTPS URL of your repository
  url: https://github.com/enterprise-org/infrastructure-manifests.git
  type: git
  
  # For HTTPS, username can be arbitrary for some providers, 
  # but must be provided. For GitHub, use the username or account name.
  username: gitops-machine-user
  
  # The Personal Access Token (PAT) with read-only scope to repository contents
  password: ghp_SecureAndLongTokenGeneratedFromGitProvider

Method C: GitHub App Authentication (Enterprise Gold Standard)

GitHub Apps are the most secure way to connect to GitHub. They bypass standard user account rate limits and use cryptographically secure, short-lived tokens.

Required GitHub App Permissions

• Repository Permissions: Contents: Read-Only (to read manifests and code) and Metadata: Read-Only (required for basic API interactions).

apiVersion: v1
kind: Secret
metadata:
  name: enterprise-git-repo-github-app
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
type: Opaque
stringData:
  # Use the HTTPS clone URL
  url: https://github.com/enterprise-org/infrastructure-manifests.git
  type: git
  
  # The GitHub App ID (found on your GitHub App settings page)
  githubAppID: "123456"
  
  # The Installation ID (found in the URL when installing the App to your Org)
  githubAppInstallationID: "98765432"
  
  # The Private Key (.pem file) generated for your GitHub App
  githubAppPrivateKey: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIEogIBAAKCAQEAs2V3f9z...
    [Insert full multiline PEM key contents here]
    -----END RSA PRIVATE KEY-----

7. Imperative Configuration (CLI and UI)

While declarative manifests are preferred for production, the CLI and UI are excellent for rapid testing, debugging, and initial configurations.

Using the ArgoCD CLI

First, ensure you are authenticated to your ArgoCD cluster via the CLI:

argocd login argocd.internal.enterprise.com --username admin --password MyPassword

Adding an SSH Repository

argocd repo add git@github.com:enterprise-org/infrastructure-manifests.git \
  --ssh-private-key-path ~/.ssh/id_ed25519 \
  --project default \
  --upsert

Adding an HTTPS Repository with Credentials

argocd repo add https://github.com/enterprise-org/infrastructure-manifests.git \
  --username gitops-machine-user \
  --password ghp_MySecureToken \
  --project default

Adding a GitHub App Repository via CLI

argocd repo add https://github.com/enterprise-org/infrastructure-manifests.git \
  --github-app-id 123456 \
  --github-app-installation-id 98765432 \
  --github-app-private-key-path ~/downloads/github-app.private-key.pem

Testing Connection Health

After adding a repository, verify its status immediately using the CLI:

argocd repo list

Expected Output:

TYPE  NAME  REPO                                                        STATUS      ASSOCIATION  CONNECTION  REASON
git         git@github.com:enterprise-org/infrastructure-manifests.git  Successful               successful  

8. Enterprise Credential Templates

In a large enterprise, managing individual secrets for hundreds of repositories is operationally expensive and error-prone. ArgoCD solves this using Repository Credential Templates (Wildcard Credentials).

By defining a credential template, you instruct ArgoCD to automatically reuse a single set of credentials for any repository URL matching a specific pattern (e.g., any repository under the enterprise-org organization).

Declarative Wildcard Secret

To configure a wildcard template, change the label to argocd.argoproj.io/secret-type: repo-creds.

apiVersion: v1
kind: Secret
metadata:
  name: enterprise-wildcard-github-creds
  namespace: argocd
  labels:
    # CRITICAL: This label marks this secret as a template, not a single repo
    argocd.argoproj.io/secret-type: repo-creds
type: Opaque
stringData:
  # Match any repository belonging to this organization
  url: https://github.com/enterprise-org
  
  # Type of VCS
  type: git
  
  # Credentials to apply to all matching repos
  githubAppID: "123456"
  githubAppInstallationID: "98765432"
  githubAppPrivateKey: |
    -----BEGIN RSA PRIVATE KEY-----
    MIIEogIBAAKCAQEAs2V3f9z...
    -----END RSA PRIVATE KEY-----

Once applied, any ArgoCD Application that references a repository URL starting with https://github.com/enterprise-org/ will automatically leverage this GitHub App credential, eliminating the need to register individual repositories beforehand.

9. Self-Hosted Git & Custom CA Certificates

Enterprise environments often host self-managed Git instances, such as GitLab Self-Managed, GitHub Enterprise Server, or Bitbucket Server. These instances are frequently secured using internal Enterprise PKI (Public Key Infrastructure) rather than public Certificate Authorities (CAs).

By default, ArgoCD will reject connections to these instances with TLS handshake errors:

x509: certificate signed by unknown authority

Configuring Custom TLS Certificates in ArgoCD

To trust your internal CA, you must register the root CA certificate inside the argocd-tls-certs-cm ConfigMap in the argocd namespace.

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-tls-certs-cm
  namespace: argocd
data:
  # The key must match the exact hostname of your self-hosted Git server
  git.internal.enterprise.com: |
    -----BEGIN CERTIFICATE-----
    MIIFdzCCBF+gAwIBAgIQD7bH5g...
    [Insert the PEM-encoded public root CA certificate here]
    -----END CERTIFICATE-----

The argocd-repo-server automatically mounts this ConfigMap and updates its system trust store. This allows secure, verified HTTPS connections to your self-hosted Git platform without resorting to the highly discouraged insecure: "true" parameter, which leaves your GitOps pipeline vulnerable to Man-in-the-Middle (MitM) attacks.

10. Multi-Tenancy & Repository Access Control

In a shared cluster environment, different teams should only access their respective Git repositories. If Team A can read Team B's Git repositories, they could potentially deploy Team B's applications or access sensitive configuration data.

ArgoCD enforces multi-tenancy boundaries using the AppProject Custom Resource Definition (CRD).

Restricting Repository Access using AppProject

The following manifest defines an AppProject that strictly limits applications within this project to a specific Git repository and a designated destination namespace.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-alpha-project
  namespace: argocd
spec:
  description: "Secure isolated project for Team Alpha"
  
  # Allow applications to only deploy from Team Alpha's repository
  sourceRepos:
    - "https://github.com/enterprise-org/team-alpha-manifests.git"
    
  # Restrict deployments to Team Alpha's designated namespace on the target cluster
  destinations:
    - namespace: team-alpha-prod
      server: https://kubernetes.default.svc
      
  # Enable namespace-scoped resource filtering (Optional but recommended)
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
  
  # Roles and RBAC mappings for Team Alpha members
  roles:
    - name: developer
      description: "Read-only access to Team Alpha applications"
      policies:
        - p, proj:team-alpha-project:developer, applications, get, team-alpha-project/*, allow
      groups:
        - "oidc-group-team-alpha"

Network Security and Egress Control

To prevent lateral movement and data exfiltration, enforce network policies that restrict outbound traffic from the argocd-repo-server pods.

• Egress to Git Provider: Restrict egress to the specific CIDR blocks of your Git provider (e.g., GitHub's public IP ranges) or internal Git server IP on TCP port 443 (HTTPS) and port 22 (SSH).
• Block other Egress: Prevent the repo-server from communicating with other pods in the cluster or arbitrary internet destinations.

11. Scaling Git Operations & Performance Tuning

At an enterprise scale (hundreds of active developers, thousands of Git repositories, and tens of thousands of resources), ArgoCD's default polling mechanism can cause performance issues:

• Git Provider Throttling: Constantly polling hundreds of repositories every 3 minutes will exhaust your GitHub/GitLab API limits quickly.
• CPU/Memory Exhaustion: Running concurrent git clone or git fetch operations places heavy demands on the argocd-repo-server's CPU and memory resources.

Solution A: Implement Webhooks (Push-Based Reconciliations)

Instead of polling, configure your Git provider to send a Webhook payload to ArgoCD whenever a commit is pushed. This changes ArgoCD's behavior from passive polling to instant, event-driven updates, reducing API consumption to near zero.

Webhook Configuration Steps:

1. In your Git Provider (e.g., GitHub), go to Settings -> Webhooks -> Add Webhook.
2. Set the Payload URL to: https://<argocd-ingress-url>/api/webhook
3. Set the Content type to: application/json
4. Generate a secure, random string to use as the Secret.
5. Select the Just the push event trigger.

Registering the Webhook Secret in ArgoCD:

ArgoCD requires the webhook secret to verify the authenticity of incoming payloads. Configure this by editing the argocd-secret:

apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
  namespace: argocd
type: Opaque
stringData:
  # The webhook secret shared with your Git provider
  webhook.github.secret: "SuperSecretWebhookTokenGeneratedAbove"

Once configured, ArgoCD will immediately reconcile resources when a commit is pushed, bypassing the 3-minute polling delay entirely.

Solution B: Optimizing argocd-repo-server Resources and Caching

In large environments, you must scale up the resources allocated to the argocd-repo-server.

Key Configurations to Tune (via Helm values or Deployment patches):

• Replicas: Scale the argocd-repo-server deployment to 3 or more replicas for high availability and load distribution.
• Parallelism Limits: Control how many concurrent manifest generations can occur. Modify the ARGOCD_REPO_SERVER_MAX_CONCURRENT_GENERATIONS environment variable (default is 120).
• Local Cache Size: Ensure the persistent volume or ephemeral storage mounted to /tmp has sufficient IOPS and capacity to prevent disk exhaustion during large clones.

# Example snippet of argocd-repo-server deployment patch
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: argocd-repo-server
          resources:
            requests:
              cpu: "1"
              memory: "1Gi"
            limits:
              cpu: "2"
              memory: "4Gi"
          env:
            - name: ARGOCD_REPO_SERVER_MAX_CONCURRENT_GENERATIONS
              value: "50"
            - name: ARGOCD_GIT_ATTEMPTS_COUNT
              value: "5"

12. Troubleshooting & Debugging

When Git connections fail, deployments halt. This section provides a structured, step-by-step diagnostic runbook for engineers.

Diagnostic Workflow

[Connection Error]
       |
       v
1. Check Repository Secret Labels
   - Is 'argocd.argoproj.io/secret-type: repository' set?
       |
       +---> No  ---> Fix labels and re-apply.
       |
       +---> Yes ---> 2. Check Network Connectivity
                        - Exec into 'argocd-repo-server' pod.
                        - Run: nc -zv github.com 443 (or 22)
                            |
                            +---> Fails ---> Check Kubernetes NetworkPolicies or Egress Firewalls.
                            |
                            +---> Works ---> 3. Test Git Handshake manually
                                             - Run: git ls-remote -q git@github.com:...
                                                 |
                                                 +---> Auth Error ---> Verify SSH Private Key or PAT permissions.
                                                 +---> Host Key Error -> Add host key to 'argocd-ssh-known-hosts-cm'.
    

Common Error Scenarios and Resolutions

Scenario 1: Host Key Verification Failed

Symptom: The repo status shows:

ssh: handshake failed: knownhosts: key is unknown

Root Cause: ArgoCD enforces strict SSH host key verification by default. It does not recognize the public key of your self-hosted Git server or public Git provider.

Resolution: Retrieve the public host key of your Git provider and add it to the argocd-ssh-known-hosts-cm ConfigMap.

# Fetch the host key
ssh-keyscan github.com

Add it to the ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-ssh-known-hosts-cm
  namespace: argocd
  labels:
    app.kubernetes.io/part-of: argocd
data:
  # The key can be any unique identifier, the value must be the keyscan output
  github.com: |
    github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl

Scenario 2: Dial TCP Timeout (Network Outage)

Symptom: The repo status shows:

dial tcp 140.82.121.4:443: i/o timeout

Root Cause: The argocd-repo-server cannot reach the external Git provider due to a network policy blocking egress, or an enterprise firewall intercepting the traffic.

Resolution: Execute a connection test directly from the running container:

kubectl exec -n argocd deploy/argocd-repo-server -c argocd-repo-server -- nc -zv github.com 443

If this fails, coordinate with your network security team to allow egress traffic from your cluster nodes to the Git provider's IP ranges.

Scenario 3: Rate Limit Exceeded

Symptom: Connection works occasionally, but frequently fails with:

HTTP 403: API rate limit exceeded for user...

Root Cause: Too many applications polling Git repositories using the same machine user account or Personal Access Token.

Resolution:

• Migrate from HTTPS PATs to GitHub Apps, which have a much higher rate limit ceiling.
• Implement Webhooks as detailed in Section 11 to dramatically reduce polling calls.
• Increase the default polling interval in the argocd-cm ConfigMap if webhooks are not possible:

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: argocd-cm
    namespace: argocd
  data:
    # Increase polling interval to 10 minutes (600 seconds)
    timeout.reconciliation: "600s"

13. Monitoring & Observability

Maintaining visibility into your Git operations ensures you can proactively identify rate limiting, slow sync times, and credential expirations before they impact development teams.

Key Prometheus Metrics for Git Connections

The argocd-repo-server exposes several standard Prometheus metrics on port 8081 (at path /metrics). Monitor these key metrics:

Example Prometheus Alerting Rule

Use this Prometheus Rule definition to alert your team when Git operations become dangerously slow, which is a common precursor to cluster synchronization failures:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: argocd-git-latency-alerts
  namespace: argocd
spec:
  groups:
  - name: argocd-git.rules
    rules:
    - alert: ArgoCDGitLatencyHigh
      expr: histogram_quantile(0.95, sum(rate(argocd_git_request_duration_seconds_bucket[5m])) by (le)) > 15
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "ArgoCD Git operation latency is high"
        description: "95% of Git operations are taking longer than 15 seconds to complete. This may indicate network latency or throttling by the Git provider."

14. Technical Interview Questions & Answers

Q1: Explain how the argocd-repo-server optimizes Git operations to avoid cloning the entire repository on every single reconciliation loop.

Answer:
The argocd-repo-server maintains a local cache of Git repositories inside its ephemeral disk storage (typically under the /tmp or /shared directory). On the initial application reconciliation, it performs a full git clone. For subsequent checks, it executes a git fetch rather than a clean clone, downloading only the delta commits. Furthermore, once the manifests are generated (e.g., via Helm template processing), the resulting YAML manifests are cached in Redis. This ensures that as long as the target commit SHA hasn't changed, ArgoCD reads the rendered manifests directly from Redis, bypassing Git operations and filesystem access entirely.

Q2: Why are GitHub Apps preferred over Personal Access Tokens (PATs) for enterprise ArgoCD deployments?

Answer:
GitHub Apps are preferred for three main reasons:

1. API Rate Limits: GitHub Apps enjoy a dedicated, significantly higher rate limit pool (typically up to 12,500 requests per hour depending on organization size) compared to the 5,000 requests per hour limit shared by all integrations using a standard user's PAT.
2. Credential Lifecycle & Security: PATs are long-lived static strings that must be manually rotated. GitHub Apps authenticate using short-lived installation tokens (valid for 1 hour) dynamically requested by ArgoCD using a local private RSA key, minimizing the risk of credential leakage.
3. Granular Auditing and Scoping: GitHub Apps can be scoped to specific repositories and granted read-only permissions on a per-resource basis (e.g., contents, metadata), whereas PATs are often tied to a single user account and grant over-privileged access.

Q3: You've configured an SSH repository connection, but the status shows "Host key verification failed". How do you resolve this without setting insecure: "true"?

Answer:
Setting insecure: "true" is unsafe because it disables host key validation, making the system vulnerable to Man-in-the-Middle (MitM) attacks. To resolve this correctly:

1. Use ssh-keyscan <git-provider-domain> (e.g., ssh-keyscan github.com) to retrieve the trusted public host key of the Git server.
2. Add this host key to the argocd-ssh-known-hosts-cm ConfigMap in the argocd namespace under a key representing the domain name.
3. ArgoCD will automatically mount this ConfigMap to its trust store, allowing the SSH handshake to complete securely.

Q4: How does ArgoCD handle credential management for hundreds of repositories belonging to the same organization without duplicating secrets?

Answer:
ArgoCD uses Repository Credential Templates (labeled with argocd.argoproj.io/secret-type: repo-creds). In this secret, the url field points to the base organization path (e.g., https://github.com/enterprise-org). When an application requests a repository under that path, ArgoCD automatically inherits the credentials defined in the template secret, eliminating the need to create individual secrets for each repository.

15. Frequently Asked Questions (FAQs)

How often does ArgoCD poll Git repositories for changes?

By default, ArgoCD polls all registered Git repositories every 3 minutes (180 seconds). You can modify this interval by setting the timeout.reconciliation parameter in the argocd-cm ConfigMap. To eliminate polling delays and API usage entirely, configure Git webhooks instead.

Can I use multiple credentials for the same Git repository URL?

No, ArgoCD