github.com/argoproj/argo-cd/v2@v2.10.5/docs/proposals/project-repos-and-clusters.md (about)

     1  ---
     2  title: Neat-enhancement-idea
     3  authors:
     4  - "@alexmt"
     5    sponsors:
     6  - TBD
     7    reviewers:
     8  - "@jessesuen"
     9  - TBD
    10    approvers:
    11  - "@jessesuen"
    12  - TBD
    13  
    14  creation-date: 2020-04-19
    15  last-updated: 2020-04-19
    16  ---
    17  
    18  # Neat Enhancement Idea
    19  
    20  Support project scoped Repositories and Clusters to enable self-service end-users onboarding.
    21  
    22  ## Summary
    23  
    24  The Argo CD has two type of users:
    25  
    26  * Administrators who configure the Argo CD and manage the Argo CD projects.
    27  * Developers who use Argo CD to manage resources in the Kubernetes clusters.
    28  
    29  These two roles enable sharing on the Argo CD instance in a multi-tenant environment. Typically the developer
    30  requests a new project from an administrator. The administrator creates the project, defines which repositories
    31  can and clusters can be used within the project which concludes the onboarding.
    32  
    33  The problem is that list of repositories and clusters are often not known during the onboarding process. Developers get
    34  it later and have to again contact an administrator, somehow share repo/cluster credentials. This back and forth
    35  process takes time and creates friction.
    36  
    37  We want to streamline the process of adding repositories and clusters to the project and make it self-service. The Argo CD
    38  admins should be able to optionally enable self onboarding of repositories/clusters for some projects.
    39  
    40  ## Motivation
    41  
    42  As long as the developer has the required credentials he/she should be able to add repository/cluster to the project
    43  without involving the administrator. To archive it, we are proposing to introduce project scoped repositories and clusters.
    44  
    45  ### Goals
    46  
    47  The goals of project scoped repositories and clusters are:
    48  
    49  #### Allow Self-Registering Repositories/Clusters in a Project
    50  
    51  Developer should be able to add a repository/cluster into the project without asking help from Argo CD administrator.
    52  
    53  ### Non-Goals
    54  
    55  #### Simplify Management of Shared Repositories/Clusters in a Project
    56  
    57  The repositories and clusters that can be used across multiple projects still have to be managed by Argo CD administrator.
    58  
    59  ## Proposal
    60  
    61  #### Project scoped repository/cluster
    62  
    63  The proposal is to introduce project scoped clusters and repositories that can be managed by a developer who has access to the project.
    64  The only difference of project scoped repository/cluster is that it has `project` field with the project name it belongs to. Both repositories
    65  and clusters are stored as Kubernetes Secrets, so a new field could be stored as a Secret data key:
    66  
    67  ```yaml
    68  apiVersion: v1
    69  kind: Secret
    70  metadata:
    71    name: argocd-example-apps
    72    labels:
    73      argocd.argoproj.io/secret-type: repository
    74  type: Opaque
    75  stringData:
    76    project: my-project1                                     # new project field
    77    name: argocd-example-apps
    78    url: https://github.com/argoproj/argocd-example-apps.git
    79    username: ****
    80    password: ****
    81  ```
    82  
    83  * The project scoped repository/cluster is automatically allowed in the project.
    84    This enables developers to allow new cluster/repository without modifying the project.
    85  * The project scoped repository/cluster still can be used in other project but it has to be allowed by admin (as normal repository/cluster).
    86  * If another team wants to add the same repository/cluster into a different project they would have to ask admin. 
    87  
    88  #### Project RBAC Changes
    89  
    90  The organization still might want to enforce certain rules so developers won't get permission to add a
    91  project-specific repository/cluster by default. The administrator might use RBAC to control access to
    92  the project scoped repositories cluster. The access to project scope actions will be checked using
    93  `<projectName>/<name>` pattern. For example, to allow users to add project scoped repositories admin would have to add
    94  the following RBAC rules:
    95  
    96  ```
    97  p, proj:my-project:admin, repositories, create, my-project/*, allow
    98  p, proj:my-project:admin, repositories, delete, my-project/*, allow
    99  p, proj:my-project:admin, repositories, update, my-project/*, allow
   100  ```
   101  
   102  This provides extra flexibility so that admin can have stricter rules. e.g.:
   103  
   104  ```
   105  p, proj:my-project:admin, repositories, update, my-project/"https://github.example.com/*", allow
   106  ```
   107  
   108  #### UI/CLI Changes
   109  
   110  Both User interface and CLI should get ability to optionally specify project. If project is specified than cluster/repository
   111  is considered project scoped:
   112  
   113  ```
   114  argocd repo add --name stable https://charts.helm.sh/stable --type helm --project my-project
   115  ```
   116  
   117  
   118  ### Use cases
   119  
   120  Add a list of detailed use cases this enhancement intends to take care of.
   121  
   122  ## Use case 1:
   123  As a developer, I would like to register credentials of a Git repository I own so I can deploy manifests stored in that repository.
   124  
   125  ## Use case 2:
   126  As a developer, I would like to register credentials of a Kubernetes cluster so I can manage resources in that cluster.
   127  
   128  ### Implementation Details/Notes/Constraints [optional]
   129  
   130  As of v2.0.1 Argo CD stores Repository non-sensitive metadata in `argocd-cm` ConfigMap. This is going to change in https://github.com/argoproj/argo-cd/issues/5436.
   131  So we would have to wait for #5436 implementation.
   132  
   133  ### Detailed examples
   134  
   135  ### Security Considerations
   136  
   137  The security considerations are explained in `Project RBAC Changes` section.
   138  
   139  ### Risks and Mitigations
   140  
   141  #### Deverlopers Might Overload Argo CD
   142  
   143  The developers are typically not responsible for Argo CD health and don't have access to Argo CD metrics. So adding too many clusters might overload Argo CD.
   144  Two improvements are proposed to mitigate that risk:
   145  
   146  **Improved Cluster Metrics**
   147  
   148  The existing metrics should be improved so that administrators could quickly discover if the project "has" too many clusters and easily discover who added the cluster:
   149  
   150  * Add `project` tag to existing cluster metrics: [clustercollector.go](https://github.com/argoproj/argo-cd/blob/bfd0b155eff4212e9354a6958e329dbd64f9a69a/controller/metrics/clustercollector.go#L20).
   151  * Document how administrator can leverage metrics to configure limits per project and get notifications when the limit is exceeded.
   152  * Add `owner` field to the cluster (and repository for consistency ) and use it to store username of the user who added cluster/repository. The administrator can use the `owner` field to contact
   153    the person who added the cluster and exceeded the limit.
   154  
   155  **Project Sharding**
   156  
   157  It should be possible to automatically assign project scoped clusters to the specific clusters shard. This way admin can isolate large projects from each other and limit the blast radius.
   158  
   159  ### Upgrade / Downgrade Strategy
   160  
   161  In case of rollback to the previous version, the project scoped clusters/repositories will be treated as normal (non-scoped) clusters/repositories.
   162  So it is safe to rollback and then roll forward.
   163  
   164  ## Open Issues
   165  
   166  If the same cluster or repository required in multiple projects that there is no way to configure it without involving Argo CD admin. The end-user
   167  would still have to reach out to the administrator and request Argo CD config changes.
   168  
   169  ## Alternatives
   170  
   171  Don't introduce first-class support for this feature and instead create optional CRD that manages clusters and repositories.
   172  In this case, the first-class support seems like a very natural fit into the existing design.