Story (Required)

In Argo CD 3.0, fine grained RBAC inheritance of Applications have been disable. Provide a first class support in operator to enable or disable this functionality. Introduce a new flag under `.spec.rbac.disableApplicationFineGrainedRBACInheritance` in ArgoCD CR which maps to `server.rbac.disableApplicationFineGrainedRBACInheritance` in `argocd-cm` configmap to control the behaviour. 

Based on slack discussion, we will continue 2.x behaviour in latest version to avoid shipping lot of breaking changes together. Therefore, the operator should set the new flag `server.rbac.disableApplicationFineGrainedRBACInheritance=false` in `argocd-cm` configmap to preserve the old RBAC behaviour. Users can override this behaviour using .spec.extraConfig in ArgoCD CR if they want to use the new fine grained rbac functionality

kind: ArgoCD
spec:
  extraConfig: |
    server.rbac.disableApplicationFineGrainedRBACInheritance: true 

We will enable upstream behaviour by default i.e disableApplicationFineGrainedRBACInheritance: true in Operator 2.0 version. 

Background and Approach (Required)

In Argo CD 3.0, fine grained RBAC inheritance of Applications have been disable. This means, the update or delete actions only apply to the application itself and not to it's deployed resources. New policies must be defined to allow the update/* or delete/* actions on an Application's managed resources.

Example:

Prior to 3.0, a rbac permission

p, example-user, applications, update, default/prod-app, allow

would give access to user "example-user" to update the Application "prod-app" as well as all it's resources like pods, services, deployments, etc. However, from 3.0, the inheritance of permissions is disabled by default. So above permission will give user "example-user" access to only update the Application "prod-app" and not it's resources. To allow access to it's resources, addition rule has to be applied as below. 

p, example-user, applications, update/*, default/prod-app, allow

More details: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#fine-grained-permissions-for-updatedelete-action 

Out of Scope

• <Defines what is not included in this story.>

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• Code changes are made to disable fine grained RBAC control on Applications. 
• .spec.extraConfig option to enabled the feature flag is tested to ensure Operator doesn't override the behaviour. 
• Release note item or Doc inputs are provided to inform users about the difference in upstream and downstream behaviour and how to enable upstream feature

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.