Skip to content

Kubernetes Code-To-Cloud Visibility

This guide provides instruction on how to achieve visibility into the source code findings that are associated with running, and potentially internet-facing Kubernetes services. This is helpful in reducing noise by being able to prioritize only the findings that exist within running software.

Prerequisites

  • An active ECR integration or the ability to add images through manual provisioning (scanning within the CI pipeline).
  • The ability to add tags to a Docker image.

Instructions

  1. Identify the Docker images that are associated with the Kubernetes services that you would like to gain visibility on. This could be done by looking through the list of running docker images (e.g. $ docker image ls).

  2. Ensure the identified Docker images have a label identifying the repository that the image should be associated with.

    Example (Dockerfile): 

        LABEL "org.opencontainers.image.source"="https://github.com/your_org/your_repo"

    Example (CLI): 

       $ docker build --label "org.opencontainers.image.source=https://github.com/your_org/your_repo"

  3. After adding the label, ensure that the image has been successfully inventoried by Boost by either publishing the image to ECR or scanning the image within the pipeline with Trivy Image.

  4. Visit the Scanner Coverage page and run a scan on the affected repository, any scanner is fine. This will refresh the state of the assets that Boost is aware of, creating the connection between any inventoried images and Kubernetes services.

  5. To observe the results of this connection, head to the Findings page and group by K8s Cluster or K8s Service.

    Kubernetes Findings Group By

    If findings associated with the Kubernetes cluster or service can be found, then the connection has been successfully made.

  6. Now that there are source code findings associated with Kubernetes assets, an opportunity to create policy rules around this key contextual information is available. Head to the Policy page and begin adding rules like Access = External or Kubernetes Cluster = {your_kubernetes_cluster} to take advantage of the end-to-end visibility.

    Kubernetes Policy