Description of Problem

• In GitOps 1.19, the ImageUpdater Custom Resource Definition (CRD) automatically aggregates "edit" and "admin" permissions to the default OpenShift roles. This allows unprivileged users to create, modify, and delete ImageUpdater instances, potentially leading to unauthorized image deployments. So, as an unprivileged user you can indeed create imageupdater instances. It appears this is occurring because certain roles are being automatically aggregated into the default edit, view, and admin roles.

Additional Info

• <Any additional info such as logs, must-gather outputs, etc.>

Problem Reproduction

• <How do we reproduce the problem?>

Reproducibility

• <Always>

Prerequisites/Environment

• <OpenShift, managed service (e.g., ROSA, ARO), operators, layered product, and other software versions, build details>

Steps to Reproduce

• Verify permissions as an unprivileged user Login as a standard user with the edit role in a namespace and check the authorization:

$ oc auth can-i create ImageUpdater
yes
$ oc auth can-i --list | grep -i imageupdater
imageupdaters.argocd-image-updater.argoproj.io [] [] [create update patch delete get list watch *]

• Inspect the aggregated ClusterRole The operator creates a ClusterRole that uses the aggregate-to-edit label. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    olm.managed: "true"
    # This label causes the rule to be added to the default 'edit' role
    rbac.authorization.k8s.io/aggregate-to-edit: "true" 
  name: imageupdaters.argocd-image-updater.argoproj.io-v1alpha1-edit
rules:
- apiGroups:
  - argocd-image-updater.argoproj.io
  resources:
  - imageupdaters
  verbs:
  - create
  - update
  - patch
  - delete   

Expected Results

• ...

Actual Results

• ...

Problem Analysis

• <Completed by engineering team as part of the triage/refinement process>

Root Cause

• <What is the root cause of the problem? Or, why is it not a bug?>

Workaround (If Possible)

• <Are there any workarounds we can provide to the customers?>

Fix Approaches

• <If we decide to fix this bug, how will we do it?>

Acceptance Criteria

• ...

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.