Uploaded image for project: 'OpenShift Autoscaling'
  1. OpenShift Autoscaling
  2. AUTOSCALE-27

BoundServiceAccountToken Authentication for OpenShift

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • None
    • BoundServiceAccountToken Authentication for OpenShift
    • BU Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • In Progress
    • OCPSTRAT-1817 - BoundServiceAccountToken Authentication for OpenShift
    • OCPSTRAT-1817BoundServiceAccountToken Authentication for OpenShift
    • 0% To Do, 0% In Progress, 100% Done

      Goal

      The goal of this epic is to allow OpenShift admins to securely configure CMA (Custom Metrics Autoscaler) to scale workloads dynamically using short-lived ServiceAccount tokens for authentication, ensuring automated token rotation and minimal manual intervention.

      Why is this important?

      • Since Kubernetes 1.22, there is the Bound service account token feature that allows short-lived tokens to be mounted as projectedVolumes to your pods. We can leverage this concept in CMA to enhance security by implementing short-lived and audience-bound ServiceAccount tokens for use in Kubernetes auth-delegated scaling workflows.
      • Currently, the only way to supply tokens as authentication parameters to your CMA scalars is by using the Secret Auth Provider which allows users to reference a `Secret` in the cluster and embed one of the fields of the `Secret` as a parameter for your KEDA authentication trigger. This is not ideal as it embeds a long-lived token in a `Secret` which can potentially be a risk to information security.

      Scenarios

      • A cluster admin creates a CMA scaler (e.g. Prometheus scaler) and wants to use short-lived ServiceAccount tokens to authenticate CMA

      Acceptance Criteria

      • Dev - Upstream implementation in GitHub
      • Dev - Downstream cherry-pick merged in GitHub and manually validated
      • CI - MUST be running successfully with tests automated
      • QE - covered in Polarion test plan and tests implemented
      • Release Technical Enablement - Must have TE slides
      • Docs - downstream docs

      Dependencies (internal and external)

      1. None

      Previous work (Optional):

      1. None

      Open questions:

      1. None for now.

      Done Checklist

      • CI - CI is running, tests are automated and merged. <link to tests in openshift/release>
      • Release Technical Enablement - <link to Feature Enablement Presentation>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Enhancement merged: N/A
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link or reference to GitHub PR>

              rh-ee-macao Max Cao
              gausingh@redhat.com Gaurav Singh
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: