Uploaded image for project: 'OpenShift BuildConfig'
  1. OpenShift BuildConfig
  2. OCPBUILD-19

Disable `builder` Service Account Generation

XMLWordPrintable

    • 8
    • False
    • Hide

      None

      Show
      None
    • False
    • SECFLOWOTL-22 - OCP Capabilities: Disable Builder Service Account
    • 8

      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 cluster admin trying to reduce the attack surface of my cluster I want to disable the generation of the builder service account.

      Background (Required)

      <Describes the context or background related to this story>

      Not all clusters want to run builds - especially in tightly regulated environments or when deploying mission-critical applications. For these clusters, the "builder" service account represents a potential avenue for attack because it grants workloads permission to push to the internal OpenShift container registry.

      Out of scope

      <Defines what is not included in this story>

      • Documentation updates related to the current RBAC granted to the "builder" service account
      • Options that allow the default service account name for builds to be changed.
      • Removal of the "builder" service account after the respective controllers have been disabled.

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      See the features described in the enhancement proposal:

      • Extend the "Build" CRD for config.openshift.io/v1 to have a new field, "builderServiceAccount"
        • Option "Generate" supports the current behavior. Use controller-gen annotations to make this a default value
        • Option "Disable" - disables the generation of builder service accounts and their associated RBAC.
      • Update cluster-openshift-controller-manager-operator to read the build CRD value and act accordingly:
        • Generate - current behavior remains in place
        • Disable - disable the controllers that create the builder service account and its associated RBAC
      • Release note describing the new configuration options
      • Update openshift-docs for the cluster Build config object with these new fields

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      • BUILD-725: Refactor service account controllers.
      • BUILD-733: Enhancement proposal to disable builder service account

      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>

      • With "Generate" option, builder service account is generated in new namespaces
      • With "Disable" option, builder service account is not created in new namespaces
      • API does not allow unsupported values, or the openshift-controller-manager-operator overwrites the value to "Generate" if it sees an unsupported value.
      • Documentation updated to describe these new configurations and cluster behavior

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated - initial estimate 8 (rounded)
      Engineering: 3
      Docs: 2
      QE: 1
      PX: 1? Unsure how to factor in metrics + telemetry
      Security: 1 (potential inform/FYI for OCP security team(s))

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

              Unassigned Unassigned
              adkaplan@redhat.com Adam Kaplan
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: