github.com/argoproj/argo-cd/v2@v2.10.5/docs/proposals/respect-rbac-for-resource-exclusions.md (about) 1 --- 2 title: Respect RBAC for Resource Inclusions/Exclusions 3 4 authors: 5 - "@gdsoumya" 6 - "@alexmt" 7 8 sponsors: 9 - TBD 10 11 reviewers: 12 - @jannfis 13 14 approvers: 15 - @jannfis 16 17 creation-date: 2023-05-03 18 19 --- 20 21 # Enhancement Idea 22 23 This is a proposal to provide the ability to configure argocd controller, to respect the current RBAC permissions 24 when handling resources besides the already existing resource inclusions and exclusions. 25 26 ## Summary 27 28 Argo CD administrator will be able to configure in `argocd-cm`, whether to enable or disable(default) the feature where the controller will 29 only monitor resources that the current service account allows it to read. 30 31 ## Motivation 32 33 Some users restrict the access of the argocd to specific resources using rbac and this feature will enable them to continue 34 using argocd without having to manually configure resource exclusions for all the resources that they don't want argocd to be managing. 35 36 ## Proposal 37 38 The configuration for this will be present in the `argocd-cm`, we will add new boolean field `resource.respectRBAC` in the 39 cm which can be set to `true` to enable this feature, by default the feature is disabled. 40 41 For the implementation there are 3 proposals : 42 43 1. Modify `gitops-engine` pkg to make a `SelfSubjectAccessReview` request before adding any resource to the watch list, in this approach we are making an extra 44 api server call to check if controller has access to the resource, this does increase the no. of kubeapi calls made but is more accurate. 45 2. Modify `gitops-engine` pkg to check for forbidden/unauthorized errors when listing for resources, this is more efficient approach as the 46 no. of kubeapi calls made does not change, but there is a chance of false positives as similar errors can be returned from kubeapi server or env specific proxies in other situations 47 3. Combine approaches 1 and 2, in this controller will check the api response for the list call, and if it receives forbidden/unauthorized it will make the `SelfSubjectAccessReview` call. 48 This approach is accurate and at the same time, only makes extra api calls if the list calls fail in the first place. 49 50 In all solutions, once controller determines that it does not have access to the resource it will stop monitoring it. 51 52 ### Implementation decision 53 54 It was decided that we will go with approach 3 from the above list, but instead of a boolean flag we will have the `resource.respectRBAC` take 3 configuration options for the users : 55 - `strict` : This will perform both the checks i.e. whether the list call response is forbidden/unauthorized and if it is make the `SelfSubjectAccessReview` call to confirm. 56 - `normal` : This will only check whether the list call response is forbidden/unauthorized and skip `SelfSubjectAccessReview` call. 57 - unset/empty : This will disable the feature and controller will continue to monitor all resources. 58 59 NOTE: By default `resource.respectRBAC` will be unset or `""` which disables the feature 60 61 Users who are okay with an increase in kube api server calls can opt for strict option while users who are concerned with higher api calls can compromise on the accuracy and opt for the normal option. 62 63 ## Security Considerations and Risks 64 65 There are no particular security risks associated with this change, this proposal rather improves the argocd controller 66 to not access/monitor resources that it does not have permission to access. 67 68 ## Upgrade / Downgrade Strategy 69 70 There is no special upgrade strategy needed, all existing argocd configmaps will continue to work 71 and old configs without the `resource.respectRBAC` config will cause no change in argocd controllers behavior. 72 73 While downgrading to older version, if the user had configured `resource.respectRBAC` previously this would be ignored completely 74 and argocd would revert to its default behavior of trying to monitor all resources.