github.com/argoproj/argo-cd@v1.8.7/docs/operator-manual/security.md (about)

     1  # Security
     2  
     3  Argo CD has undergone rigorous internal security reviews and penetration testing to satisfy [PCI
     4  compliance](https://www.pcisecuritystandards.org) requirements. The following are some security
     5  topics and implementation details of Argo CD.
     6  
     7  ## Authentication
     8  
     9  Authentication to Argo CD API server is performed exclusively using [JSON Web Tokens](https://jwt.io)
    10  (JWTs). Username/password bearer tokens are not used for authentication. The JWT is obtained/managed
    11  in one of the following ways:
    12  
    13  1. For the local `admin` user, a username/password is exchanged for a JWT using the `/api/v1/session`
    14     endpoint. This token is signed & issued by the Argo CD API server itself, and has no expiration.
    15     When the admin password is updated, all existing admin JWT tokens are immediately revoked.
    16     The password is stored as a bcrypt hash in the [`argocd-secret`](https://github.com/argoproj/argo-cd/blob/master/manifests/base/config/argocd-secret.yaml) Secret.
    17  
    18  2. For Single Sign-On users, the user completes an OAuth2 login flow to the configured OIDC identity
    19     provider (either delegated through the bundled Dex provider, or directly to a self-managed OIDC
    20     provider). This JWT is signed & issued by the IDP, and expiration and revocation is handled by
    21     the provider. Dex tokens expire after 24 hours.
    22  
    23  3. Automation tokens are generated for a project using the `/api/v1/projects/{project}/roles/{role}/token`
    24     endpoint, and are signed & issued by Argo CD. These tokens are limited in scope and privilege,
    25     and can only be used to manage application resources in the project which it belongs to. Project
    26     JWTs have a configurable expiration and can be immediately revoked by deleting the JWT reference
    27     ID from the project role.
    28  
    29  ## Authorization
    30  
    31  Authorization is performed by iterating the list of group membership in a user's JWT groups claims,
    32  and comparing each group against the roles/rules in the [RBAC](../rbac) policy. Any matched rule
    33  permits access to the API request.
    34  
    35  ## TLS
    36  
    37  All network communication is performed over TLS including service-to-service communication between
    38  the three components (argocd-server, argocd-repo-server, argocd-application-controller). The Argo CD
    39  API server can enforce the use of TLS 1.2 using the flag: `--tlsminversion 1.2`.
    40  
    41  ## Sensitive Information
    42  
    43  ### Secrets
    44  
    45  Argo CD never returns sensitive data from its API, and redacts all sensitive data in API payloads
    46  and logs. This includes:
    47  
    48  * cluster credentials
    49  * Git credentials
    50  * OAuth2 client secrets
    51  * Kubernetes Secret values
    52  
    53  ### External Cluster Credentials
    54  
    55  To manage external clusters, Argo CD stores the credentials of the external cluster as a Kubernetes
    56  Secret in the argocd namespace. This secret contains the K8s API bearer token associated with the
    57  `argocd-manager` ServiceAccount created during `argocd cluster add`, along with connection options
    58  to that API server (TLS configuration/certs, aws-iam-authenticator RoleARN, etc...).
    59  The information is used to reconstruct a REST config and kubeconfig to the cluster used by Argo CD
    60  services.
    61  
    62  To rotate the bearer token used by Argo CD, the token can be deleted (e.g. using kubectl) which
    63  causes kubernetes to generate a new secret with a new bearer token. The new token can be re-inputted
    64  to Argo CD by re-running `argocd cluster add`. Run the following commands against the *_managed_*
    65  cluster:
    66  
    67  ```bash
    68  # run using a kubeconfig for the externally managed cluster
    69  kubectl delete secret argocd-manager-token-XXXXXX -n kube-system
    70  argocd cluster add CONTEXTNAME
    71  ```
    72  
    73  To revoke Argo CD's access to a managed cluster, delete the RBAC artifacts against the *_managed_*
    74  cluster, and remove the cluster entry from Argo CD:
    75  
    76  ```bash
    77  # run using a kubeconfig for the externally managed cluster
    78  kubectl delete sa argocd-manager -n kube-system
    79  kubectl delete clusterrole argocd-manager-role
    80  kubectl delete clusterrolebinding argocd-manager-role-binding
    81  argocd cluster rm https://your-kubernetes-cluster-addr
    82  ```
    83  <!-- markdownlint-disable MD027 -->
    84  > NOTE: for AWS EKS clusters, [aws-iam-authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator)
    85    is used to authenticate to the external cluster, which uses IAM roles in lieu of locally stored
    86    tokens, so token rotation is not needed, and revocation is handled through IAM.
    87  <!-- markdownlint-enable MD027 -->
    88  
    89  ## Cluster RBAC
    90  
    91  By default, Argo CD uses a [clusteradmin level role](https://github.com/argoproj/argo-cd/blob/master/manifests/base/application-controller/argocd-application-controller-role.yaml)
    92  in order to:
    93  
    94  1. watch & operate on cluster state
    95  2. deploy resources to the cluster
    96  
    97  Although Argo CD requires cluster-wide **_read_** privileges to resources in the managed cluster to
    98  function properly, it does not necessarily need full **_write_** privileges to the cluster. The
    99  ClusterRole used by argocd-server and argocd-application-controller can be modified such
   100  that write privileges are limited to only the namespaces and resources that you wish Argo CD to
   101  manage.
   102  
   103  To fine-tune privileges of externally managed clusters, edit the ClusterRole of the `argocd-manager-role`
   104  
   105  ```bash
   106  # run using a kubeconfig for the externally managed cluster
   107  kubectl edit clusterrole argocd-manager-role
   108  ```
   109  
   110  To fine-tune privileges which Argo CD has against its own cluster (i.e. `https://kubernetes.default.svc`),
   111  edit the following cluster roles where Argo CD is running in:
   112  
   113  ```bash
   114  # run using a kubeconfig to the cluster Argo CD is running in
   115  kubectl edit clusterrole argocd-server
   116  kubectl edit clusterrole argocd-application-controller
   117  ```
   118  
   119  !!! tip
   120      If you want to deny ArgoCD access to a kind of resource then add it as an [excluded resource](declarative-setup.md#resource-exclusion).
   121  
   122  ## Auditing
   123  
   124  As a GitOps deployment tool, the Git commit history provides a natural audit log of what changes
   125  were made to application configuration, when they were made, and by whom. However, this audit log
   126  only applies to what happened in Git and does not necessarily correlate one-to-one with events
   127  that happen in a cluster. For example, User A could have made multiple commits to application
   128  manifests, but User B could have just only synced those changes to the cluster sometime later.
   129  
   130  To complement the Git revision history, Argo CD emits Kubernetes Events of application activity,
   131  indicating the responsible actor when applicable. For example:
   132  
   133  ```bash
   134  $ kubectl get events
   135  LAST SEEN   FIRST SEEN   COUNT   NAME                         KIND          SUBOBJECT   TYPE      REASON               SOURCE                          MESSAGE
   136  1m          1m           1       guestbook.157f7c5edd33aeac   Application               Normal    ResourceCreated      argocd-server                   admin created application
   137  1m          1m           1       guestbook.157f7c5f0f747acf   Application               Normal    ResourceUpdated      argocd-application-controller   Updated sync status:  -> OutOfSync
   138  1m          1m           1       guestbook.157f7c5f0fbebbff   Application               Normal    ResourceUpdated      argocd-application-controller   Updated health status:  -> Missing
   139  1m          1m           1       guestbook.157f7c6069e14f4d   Application               Normal    OperationStarted     argocd-server                   admin initiated sync to HEAD (8a1cb4a02d3538e54907c827352f66f20c3d7b0d)
   140  1m          1m           1       guestbook.157f7c60a55a81a8   Application               Normal    OperationCompleted   argocd-application-controller   Sync operation to 8a1cb4a02d3538e54907c827352f66f20c3d7b0d succeeded
   141  1m          1m           1       guestbook.157f7c60af1ccae2   Application               Normal    ResourceUpdated      argocd-application-controller   Updated sync status: OutOfSync -> Synced
   142  1m          1m           1       guestbook.157f7c60af5bc4f0   Application               Normal    ResourceUpdated      argocd-application-controller   Updated health status: Missing -> Progressing
   143  1m          1m           1       guestbook.157f7c651990e848   Application               Normal    ResourceUpdated      argocd-application-controller   Updated health status: Progressing -> Healthy
   144  ```
   145  
   146  These events can be then be persisted for longer periods of time using other tools as
   147  [Event Exporter](https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/event-exporter) or
   148  [Event Router](https://github.com/heptiolabs/eventrouter).
   149  
   150  ## WebHook Payloads
   151  
   152  Payloads from webhook events are considered untrusted. Argo CD only examines the payload to infer
   153  the involved applications of the webhook event (e.g. which repo was modified), then refreshes
   154  the related application for reconciliation. This refresh is the same refresh which occurs regularly
   155  at three minute intervals, just fast-tracked by the webhook event.