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

Changes to RBAC with Dex SSO Authentication

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Undefined Undefined
    • 1.17.0
    • None
    • None
    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • Hide
      Before this doc update, the Argo CD Operator documentation did not include comprehensive coverage of the breaking changes that Argo CD 3.0 brought in, particularly regarding RBAC with Dex SSO authentication and the migration from encoded sub claims to federated_claims.user_id. 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, and best practices for RBAC management in the new hands-off approach. Now, users of the Argo CD Operator have clear instructions on how to decode legacy sub claims, migrate their policies to use the new federated_claims.user_id format, implement proper RBAC strategies, and understand the operator's new approach to RBAC management, ensuring they can properly handle the breaking changes that Argo CD 3.0 introduced when using the operator




      Test Purpose
      The test validates the Dex SSO authentication changes introduced in Argo CD 3.0+, specifically the migration from encoded sub claims to federated_claims.user_id for RBAC policies.

      What the Test Validates

      1. Legacy Policy Detection:
      Tests that ArgoCD can handle legacy RBAC policies using encoded sub claims (simulating Argo CD 2.x behavior)
      Example: ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA
      2. Policy Migration Process:
      Verifies that RBAC policies can be successfully migrated to use federated_claims.user_id
      Example: test@example.com instead of encoded claims
      3. Authentication & Authorization:
      Confirms that Applications can be created and managed after the migration
      Tests both user-specific and group-based RBAC policies
      4. Validates that the new authentication mechanism works correctly
      Backward Compatibility:
      5. Ensures that group-based policies continue to work (these don't need migration)
      Verifies that the ArgoCD operator properly handles the transition

      Test Steps
      1. Initial Setup: Creates ArgoCD with Dex SSO and legacy RBAC policies
      2. Migration: Updates RBAC policies to use the new federated_claims.user_id format
      3. Validation: Creates test Applications to verify authentication/authorization works
      4. Group Testing: Tests group-based policies (which remain unchanged)
      5. Cleanup: Removes test resources

      Show
      Before this doc update, the Argo CD Operator documentation did not include comprehensive coverage of the breaking changes that Argo CD 3.0 brought in, particularly regarding RBAC with Dex SSO authentication and the migration from encoded sub claims to federated_claims.user_id. 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, and best practices for RBAC management in the new hands-off approach. Now, users of the Argo CD Operator have clear instructions on how to decode legacy sub claims, migrate their policies to use the new federated_claims.user_id format, implement proper RBAC strategies, and understand the operator's new approach to RBAC management, ensuring they can properly handle the breaking changes that Argo CD 3.0 introduced when using the operator Test Purpose The test validates the Dex SSO authentication changes introduced in Argo CD 3.0+, specifically the migration from encoded sub claims to federated_claims.user_id for RBAC policies. What the Test Validates 1. Legacy Policy Detection: Tests that ArgoCD can handle legacy RBAC policies using encoded sub claims (simulating Argo CD 2.x behavior) Example: ChdleGFtcGxlQGFyZ29wcm9qLmlvEgJkZXhfY29ubl9pZA 2. Policy Migration Process: Verifies that RBAC policies can be successfully migrated to use federated_claims.user_id Example: test@example.com instead of encoded claims 3. Authentication & Authorization: Confirms that Applications can be created and managed after the migration Tests both user-specific and group-based RBAC policies 4. Validates that the new authentication mechanism works correctly Backward Compatibility: 5. Ensures that group-based policies continue to work (these don't need migration) Verifies that the ArgoCD operator properly handles the transition Test Steps 1. Initial Setup: Creates ArgoCD with Dex SSO and legacy RBAC policies 2. Migration: Updates RBAC policies to use the new federated_claims.user_id format 3. Validation: Creates test Applications to verify authentication/authorization works 4. Group Testing: Tests group-based policies (which remain unchanged) 5. Cleanup: Removes test resources
    • GitOps Tangerine Sprint 17, GitOps Tangerine Sprint 18

      Story (Required)

      • <Describes high-level purpose and goal for this story. Answers the questions: Who is impacted, what is it, and why do we need it? How does it improve the customer's experience?>
      • As a <PERSONA> trying to <ACTION>, I want <THIS OUTCOME>.

      Background and Approach (Required)

      • <Describes the context or background related to this story. Include deeper motivation of user/persona if relevant (5 whys)>
      • <Description of the general technical path on how to achieve the goal of the story. Include details like JSON schema, class definitions.>

      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: