Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-6886

Logs RBAC enforcement as a first-class RBAC citizen

XMLWordPrintable

    • 5
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Before this update, the Argo CD Operator documentation did not document how logs RBAC enforcement works in Argo CD 3.0, where logs are treated as a first-class RBAC resource that requires explicit permissions, unlike in Argo CD 2.x where users with applications access automatically got logs access. With this update, comprehensive documentation has been added to the operator documentation that includes detailed migration guides, step-by-step remediation procedures, practical examples for updating RBAC policies to include logs permissions, and best practices for RBAC management in the new hands-off approach
      Show
      Before this update, the Argo CD Operator documentation did not document how logs RBAC enforcement works in Argo CD 3.0, where logs are treated as a first-class RBAC resource that requires explicit permissions, unlike in Argo CD 2.x where users with applications access automatically got logs access. With this update, comprehensive documentation has been added to the operator documentation that includes detailed migration guides, step-by-step remediation procedures, practical examples for updating RBAC policies to include logs permissions, and best practices for RBAC management in the new hands-off approach
    • 5
    • GitOps Tangerine Sprint 16, GitOps Tangerine Sprint 17, GitOps Tangerine Sprint 18

      Story (Required)

      • As an OpenShift GitOps Administrator managing user access, I want explicit Logs RBAC enforcement enabled by default, so that access to application logs is strictly governed by explicitly defined RBAC permissions. This ensures improved security and adherence to the principle of least privilege, enhancing overall system reliability and customer trust.

       
      Background and Approach (Required)

      • In Argo CD version 3.0, the Logs RBAC enforcement flag (server.rbac.log.enforce.enable) has been removed, making explicit Logs RBAC enforcement mandatory by default. Previously, users with access to applications automatically received access to logs unless specifically restricted. The new default behavior enforces explicit permissions for accessing logs.
      • This change was introduced in the upstream Argo CD PR #21678.
      • To implement this change, the operator-managed configuration (argocd-cm ConfigMap) should no longer include the server.rbac.log.enforce.enable setting. Instead, administrators must explicitly grant log access permissions via RBAC policies defined in argocd-rbac-cm. This transition requires clear documentation to guide users in defining appropriate permissions, either globally or per role/user basis, to maintain secure and appropriate access levels.

      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)

      • <Describe edge cases to consider when implementing the story and defining tests.>
      • <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story.>

      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.

              rh-ee-atali Atif Ali
              rh-ee-anjoseph Anand Francis Joseph
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: