A team owns its own Argo CD AppProject and can commit anything to the repository that project allows. How can that still let them take over the whole cluster, and which AppProject fields prevent it?

## The mechanism the question turns on In a normal Kubernetes workflow, what you can create is bounded by your own identity: the API server authenticates you and RBAC decides. GitOps breaks that link on purpose. The delivery agent — here, Argo CD's application controller — reads manifests from Git and applies them with **its own** credential to the destination cluster. Git commit authorship is not a Kubernetes identity and is never presented to the API server. The consequence is direct: **whatever the agent can do, a committer can do**, if there is no fence in between. Argo CD registers each managed cluster as a Secret in its namespace carrying that cluster's credential, and `argocd cluster add` by default installs a service account bound to full cluster administration. A tenant who commits ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: totally-normal subjects: - kind: User name: [email protected] roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.authorization.k8s.io ``` into a path an Application syncs has just granted themselves cluster administration, and the audit log will show the deploy agent doing it. Variants are worse and quieter: a validating or mutating webhook configuration that intercepts every admission request, a DaemonSet with host mounts, a workload placed in `kube-system` where it inherits trust by convention. ## The fences, in order of usefulness **`clusterResourceWhitelist`.** Cluster-scoped kinds are where escalation lives — ClusterRole, ClusterRoleBinding, webhook configurations, CustomResourceDefinition, PriorityClass, and Namespace itself. An AppProject that lists nothing in `clusterResourceWhitelist` permits no cluster-scoped kind at all, which is the right posture for an application team. If a tenant legitimately needs one, whitelist that group and kind explicitly: ```yaml clusterResourceWhitelist: - group: '' kind: Namespace ``` **`destinations`.** Each entry pairs a cluster (by `server` URL or by `name`) with a `namespace`. Restricting the project to the team's namespaces stops the "deploy into kube-system" move and stops a manifest from reaching a cluster the team does not own. Watch for over-broad glob patterns here — a namespace pattern that is a bare `*` gives back everything you just took away. **`namespaceResourceBlacklist`.** Some namespaced kinds are platform policy rather than application config: ResourceQuota, LimitRange, NetworkPolicy. Blacklisting them keeps a tenant from raising its own quota or opening its own network policy while still letting it deploy freely. **`sourceRepos`.** Keeping the project pointed at repositories the tenant does not solely control lets you rely on the repository's review rules; a project allowing `*` means the fence is only as good as the least-protected repository anyone can reference. ## The credential behind the fence Project fields are enforced by Argo CD, so they are only as strong as Argo CD's integrity. Defence in depth means the destination credential itself should be scoped. `argocd cluster add` accepts a namespace restriction so the registered service account is granted rights only in named namespaces; on a genuinely hostile-tenant boundary, a separate cluster with its own credential beats a namespace split. Where the destination is the same cluster Argo CD runs in, remember that the controller can otherwise reach everything in it. Some Argo CD versions offer an opt-in sync **impersonation** feature, where the sync uses a service account named by the AppProject destination rather than the controller's own credential, which puts Kubernetes RBAC back in the path. It is off by default and has been staged in as an experimental capability, so treat it as an upgrade to evaluate, not as the baseline to assume in an interview answer. ## Who may edit the project Every fence above lives in an object. If the tenant can edit that object, the fence is decorative. In Argo CD RBAC the AppProject is the `projects` resource, and `update` on it must stay with the platform team; delegate inside the project through `spec.roles` instead. The same logic applies to the manifest repository holding your AppProject definitions if you manage Argo CD with Argo CD — that repository is a control-plane repository and needs review rules to match. ## How to answer it Say the mechanism first — the agent's credential, not the committer's, applies the manifest — then name `clusterResourceWhitelist` and `destinations` as the specific fields, then add the two things that make the fence real: a scoped cluster credential, and keeping project edits away from the tenant.