Problem statement

See https://docs.google.com/document/d/11lnOIaEnSLwOdTdofFH-CQ9ObG77t4F_1zfa2RS77fk/edit# for a thorough view on the problem statement

Epic Goal

The goal of this epic is to have Argo CD's application controller follow the Kubernetes RBAC permissions it's been assigned, instead of needing Kubernetes RBAC to follow Argo CD requirements.

In general, the outcome should be that whatever Kubernetes RBAC is assigned to the Argo CD application controller pod(s), Argo CD should automatically refrain from managing resources it does not have permissions for.

Why is this important?

• It will help us in giving each Argo CD instance exactly the permission it requires, instead of too broad ones as we need to do right now
• The change will reduce/prevent the need for redundant (and possibly error prone) configuration of keeping resource inclusions/exclusions in sync with Kubernetes RBAC
• The change will improve Argo CD's security as well as the security of our tenants and our infrastructure by enabling us to implement the least-privilege principle
• It provides a way better user experience than today

Scenarios

1. ...

Acceptance Criteria (Mandatory)

• Argo CD will not error on certain types of errors (such as permission denied) when building the cluster cache
• Argo CD will dynamically manage a portion of the resource inclusion/exclusion list, for example consider the following flow:
  • Permission to an API is denied by K8s RBAC, that GVK will be put on the implicit portion of the resource exclusion list automatically
  • If that GVK is later allowed by K8s RBAC, and the resource is on the implicit part of the resource exclusion/inclusion list, it will be removed from the implicit part of the resource exclusion/inclusion list so it can be effectively be managed again without need for restarting pods
• The explicit part of the resource exclusion/inclusion list must not be touched (e.g. user configured inclusion/exclusion lists must stay as-is)
• Both implicit and explicit lists must be merged when making the decision about inclusion/exclusion is being made

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment