This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Security Overview

Unerstand Kf’s security posture.

    Kf aims to provide a similar developer experience to Cloud Foundry, replicating the build, push, and deploy lifecycle. It does this by building a developer UX layer on top of widely-known, broadly used and adopted technologies like Kubernetes, Istio, and container registries rather than by implementing all the pieces from the ground up.

    When making security decisions, Kf aims to provide complete solutions that are native to their respective components and can be augmented with other mechanisms. Breaking that down:

    • Complete solutions means that Kf tries not to provide partial solutions that can lead to a false sense of security.
    • Native means that the solutions should be a part of the component rather than a Kf construct to prevent breaking changes.
    • Can be augmented means the approach Kf takes should work seamlessly with other Kubernetes and Google Cloud tooling for defense in depth.

    Important considerations

    In addition to the Current limitations described below, it is important that you read through and understand the items outlined in this section.

    Workload Identity

    By default, Kf uses Workload Identity to provide secure delivery and rotation of the Service Account credentials used by Kf to interact with your Google Cloud Project. Workload Identity achieves this by mapping a Kubernetes Service Account (KSA) to a Google Service Account (GSA). The Kf controller runs in the kf namespace and uses a KSA named controller mapped to your GSA to do the following things:

    1. Write metrics to Stackdriver
    2. When a new Kf space is created (kf create-space), the Kf controller creates a new KSA named kf-builder in the new space and maps it to the same GSA.
    3. The kf-builder KSA is used by Tekton to push and pull container images to Google Container Registry (gcr.io)

    This diagram illustrates those interactions:

    Workload identity overview diagram

    NFS

    In order to mimic Cloud Foundry’s UID/GID mapping, containers in Kf that mount NFS volumes need the ability to run as root and the ability to access the FUSE device of the kernel running the Node.

    Current limitations

    • A developer pushing an app with Kf can also create Pods (with kubectl) that can use the kf-builder KSA with the permissions of its associated GSA.

    • Kf uses the same Pod to fetch, build, and store images. Assume that any credentials that you provide can be known by the authors and publishers of the buildpacks you use.

    • Kf doesn’t support quotas to protect against noisy neighbors. Use Kubernetes resource quotas.

    Other resources

    Google Cloud

    General

    Advanced protections