Uploaded image for project: 'Red Hat Advanced Cluster Security'
  1. Red Hat Advanced Cluster Security
  2. ROX-28019

Identify platform workloads using image signature

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • None
    • Identify platform components using image signature
    • Product / Portfolio Work
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • To Do
    • ROX-26858 - View and Customize Platform Components
    • 0

      (From shesselm@redhat.com in this slack thread)

      The current approach for identifying platform workloads is built upon regex matching on the namespace level. For example, workloads from namespaces such as openshift-* and stackrox would be categorized as platform components. There are several shortcomings of this approach:

      • Completeness: How to guarantee that we include all system namespaces? What about all layered products like ACS, ACM, compliance operator, …?
      • Correctness: What if somebody manages to create a user workload inside a system namespace? What if a system namespace does not exist, and is then created by a user (think installing ACS into a namespace stackrox-operator and then creating a namespace stackrox with arbitrary workloads). Recall that this is possible in ACS, there is no guarantee that stackrox namespace is used.
      • Flexibility: Differenet platforms have different system namespaces. A static list does not provide the flexibility to make adjustments for OpenShift, EKS, AKS, GKE, … Also system namespaces may change in between different versions, which makes it very difficult for a static list to be correct.

      Instead of statically classifying workloads based on their namespace, we should look at the workload’s image signature. Red Hat is establishing Konflux as the next-gen build system, and it offers native image signing. We should be able to tell system components based on their Red Hat signature. We could do the same for other platforms, e.g. Microsoft/AWS/GCP signed images will be classified as platform components. We could even let customers define their own signature pool and give them the full flexibility to categorize their workloads.
       
      The way it would work is roughly like this:

      • Red Hat Konflux produces downstream images signed with issuers like redhat/openshift, redhat/acs, redhat/acm, … Now all OpenShift platform workloads will run images signed by redhat/openshift. All ACS images - like Central / Sensor - would be signed with redhat/acs , and so on. In ACS Central we then ship a pre-configured list of known platform signatures like redhat/* (we already support regex for image issuers, so composition is easy). Customers could then modify this list and perhaps add their own platform component issuer like my-company/platform-component .
      • This way we get completeness for free: technology to check all cluster workloads for image signatures already exists in ACS today - no matter the namespace. Correctness is proven by verifying the workload image signature, and flexibility can be achieved by regex matching a customizable list of image issuers (similar to how image signature policies already work today).
      • Now the big caveat to this approach is that it assumes that Red Hat will establish a supply chain of trusted container images with stable image signatures / issuers. As far as I know this is happening with Konflux, but we can also take some influence to make sure it happens the way we need it.

              Unassigned Unassigned
              rh-ee-klape Kyle Lape
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: