Exercise gitops-app: how to prevent developer privilege escalation via GitOps?

[donaldsebleung]

The "gitops-app" exercise has the following setup:

1. The "admin" user is a cluster administrator

2. The "project-admin" user is an administrator in the "etherpad-devs" project managed by the ArgoCD instance in the "gitops-app" project

3. The "project-admin" user is an administrator in the ArgoCD instance within the "gitops-app" project

4. The "developer" user has view permissions in the "etherpad-devs" project

5. The "developer" user has view permissions in the ArgoCD instance within the "gitops-app" project

6. The "developer" user has full control over the "etherpad-app" Git repository which can be used to deploy resources to the "etherpad-devs" project via GitOps

The intention is that the developer defines the application manifests in the "etherpad-app" Git repository which is then deployed to the "etherpad-devs" project via GitOps. However, wouldn't it be possible for the developer to include a RoleBinding manifest in the Git repository to escalate their privileges to project admin in "etherpad-devs"? Afterwards, the developer can make ad-hoc changes to the project outside of GitOps and perhaps invite other users as well.

Is my understanding of the setup and potential privilege escalation path correct? If so, what are some of the measures cluster and project administrators can take to prevent such incidents or be alerted when such a privilege escalation occurs?

[Rilindo · Accepted solution]

@donaldsebleung In most companies, you wouldn't commit a change on the main branch. Instread, the main branch will be locked and you would create a branch to make a change and then have it reviewed before it gets merged. That is how priviledge escalation like what you described gets intercepted. 

[donaldsebleung]

Makes sense, thanks for the insight!