Installing Tanzu Build Service

Page last updated:

This topic describes how to install and configure Tanzu Build Service.

Prerequisites

Before you install Build Service, you must:

  • Be on Kubernetes cluster v1.18 or later

  • Have access to the Kubernetes cluster satisfying the minimum required permissions.

  • Ensure that all worker nodes have at least 50 GB of ephemeral storage allocated to them.

    • To do this on TKGs, mount a 50GB volume at /var/lib to the worker nodes in the TanzuKubernetesCluster resource that corresponds to your TKGs cluster. These instructions show how to configure storage on worker nodes.
  • Have access to a container registry to install Tanzu Build Service and store the application images that will be created.

    • Although the documentation references specific registries for the purpose of providing examples, any registry that adheres to the Docker Registry HTTP API V2 is supported
    • TBS uses ~5GB of registry space for installation, this does not include the space that will be used for application images.
  • Ensure your Kubernetes cluster is configured with default StorageClass. Tanzu Build Service will default to using 2G of cache if a default StorageClass is defined. Build Service utilizes PersistentVolumeClaims to cache build artifacts, which reduces the time of subsequent builds.

    For more information, see Persistent Volumes in the Kubernetes documentation. And for information on defining a default StorageClass, see Changing the default StorageClass

  • Download four Carvel CLIs for your operating system. These tools will facilitate the installation of Tanzu Build Service on your cluster. They can be found on their respective Tanzu Network pages:

    • kapp is a deployment tool that allows users to manage Kubernetes resources in bulk.
    • ytt is a templating tool that understands YAML structure.
    • kbld is needed to map relocated images to k8s config.
    • imgpkg is tool that relocates container images and pulls the release configuration files. Note: imgpkg 0.12.0 or higher is required for installation. If it is not available on TanzuNet, it can be found here
  • Navigate to the following pages in Tanzu Network and accept all EULAs highlighted in yellow.

  • Find the latest Tanzu Build Service version by checking the Tanzu Build Service page on Tanzu Network. Just knowing the version is sufficient.

  • Download the kp CLI for your operating system from the Tanzu Build Service page on Tanzu Network. The kp CLI help text is published here.

    • These docs assume kp cli v0.3.* from TBS release v1.2.*. If a feature is not working, you may need to upgrade your cli.
  • Download the docker CLI to authenticate with registries.

  • Download the Dependency Descriptor file (descriptor-<version>.yaml) from the latest release on the Tanzu Build Service Dependencies page on Tanzu Network. This file contains paths to images that contain dependency resources Tanzu Build Service needs to execute image builds.

Note: Clusters running with Containerd 1.4.1 are not compatible with TBS. Notably, TKG 1.2.1 uses this version of Containerd, a different TKG version must be used.

Note: TKGs clusters running Kubernetes 1.20.0-1.20.6 are not compatible with TBS. You must k8s 1.18, 1.19, or 1.20.7+ when using TKGs.

Installing

Create a kubernetes cluster where you would like to install build service and target the cluster as follows:

kubectl config use-context <CONTEXT-NAME>

Relocate Images to a Registry

This procedure relocates images from the Tanzu Network registry to an internal image registry.

  1. Log in to the image registry where you want to store the images by running:
docker login <IMAGE-REGISTRY>

Where IMAGE-REGISTRY is the name of the image registry where you want to store the images.

  1. Log in to the Tanzu Network registry with your Tanzu Network credentials:
docker login registry.pivotal.io
  1. Relocate the images with the Carvel tool imgpkg by running:
imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo <IMAGE-REPOSITORY>

Where TBS-VERSION is the version of Tanzu Build Service you want to install and IMAGE-REPOSITORY is the repository in your registry that you want to relocate images to.

Note: When relocating, the IMAGE-REPOSITORY must be the IMAGE-REGISTRY appended with the destination repository for the images. For example, IMAGE-REGISTRY/build-service.

Exception: When relocating to Dockerhub, you must provide the Dockerhub repository and an image name that imgpkg will use for relocation. For example, my-dockerhub-account/build-service.

For example:

  • Dockerhub imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo my-dockerhub-account/build-service
  • GCR imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo gcr.io/my-project/build-service
  • Artifactory imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo artifactory.com/my-project/build-service
  • Harbor imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo harbor.io/my-project/build-service

Note: During relocation, imgpkg will report the following:
Skipped layer due to it being non-distributable. If you would like to include non-distributable layers, use the --include-non-distributable flag.
This is due to windows-based images shipped with TBS and can be ignored. For more details see the faq.

Install Tanzu Build Service

There are two ways to install Tanzu Build Service:

  1. Using a public registry (eg. GCR, Dockerhub) or an internal registry that uses a trusted certificate (eg. Let’s Encrypt)
  2. Using an internal registry that uses a self-signed CA certificate (eg. Harbor, Artifactory)

Install Tanzu Build Service Public Registry

  1. Pull the Tanzu Build Service bundle image locally using imgpkg:
imgpkg pull -b "<IMAGE-REPOSITORY>:<TBS-VERSION>" -o /tmp/bundle

Where TBS-VERSION and IMAGE-REPOSITORY are the same values used during relocation.

  1. Use the Carvel tools kapp, ytt, and kbld to install Build Service and define the required Build Service parameters:

Tanzu Build Service 1.2 ships with a dependency updater that can update ClusterStacks, ClusterStores, ClusterBuilders, and the CNB Lifecycle from TanzuNet automatically. Enabling this feature will keep Images up to date with the latest security patches and fixes. To enable this feature, pass in your TanzuNet credentials when running the install command below:

ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    -v tanzunet_username='<TANZUNET-USERNAME>' \
    -v tanzunet_password='<TANZUNET-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

You can check the status of the DependencyUpdater by running kubectl -n build-service get TanzuNetDependencyUpdater dependency-updater -o yaml

Alternatively, if you prefer to manage dependencies yourself, simply leave the TanzuNet credentials out of the install.

ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

Where:

  • IMAGE-REPOSITORY is the image repository where Tanzu Build Service images exist.

    Note: This is identical to the IMAGE-REPOSITORY argument provided during imgpkg relocation command.

    Exception: When using Dockerhub as your registry target, only use your DockerHub account for this value. For example, my-dockerhub-account (without /build-service). Otherwise, you will encounter an error similar to: Error: invalid credentials, ensure registry credentials for 'index.docker.io/my-dockerhub-account/build-service/tanzu-buildpacks_go' are available locally

  • REGISTRY-USERNAME is the username you use to access the registry. gcr.io expects _json_key as the username when using JSON key file authentication.
  • REGISTRY-PASSWORD is the password you use to access the registry.

    Note: Managing Secrets for more information about how the registry username and password are used in Tanzu Build Service.

  • TANZUNET-USERNAME is the username you use to access TanzuNet
  • TANZUNET-PASSWORD is the password you use to access TanzuNet

Installing with a CA certificate for internal registry

To install Tanzu Build Service with an internal registry that requires providing a CA certificate such as Harbor, use the normal installation command with the CA certificate file passed in with a -f flag:

ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -f <PATH-TO-CA> \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

Where:

  • PATH-TO-CA is the path to the registry root CA. This CA is required to enable Build Service to interact with internally deployed registries. This is the CA that was used while deploying the registry.
  • IMAGE-REPOSITORY is the image repository where Tanzu Build Service images exist.

    Note: This is identical to the IMAGE-REPOSITORY argument provided during imgpkg relocation command.

    Exception: When using Dockerhub as your registry target, only use your DockerHub account for this value. For example, my-dockerhub-account (without /build-service). Otherwise, you will encounter an error similar to: Error: invalid credentials, ensure registry credentials for 'index.docker.io/my-dockerhub-account/build-service/tanzu-buildpacks_go' are available locally

  • REGISTRY-USERNAME is the username you use to access the registry. gcr.io expects _json_key as the username when using JSON key file authentication.
  • REGISTRY-PASSWORD is the password you use to access the registry.

    Note: Managing Secrets for more information about how the registry username and password are used in Tanzu Build Service.

Import Tanzu Build Service Dependencies

Note: Tanzu Build Service 1.2 ships with a automatic dependency updater. If you have enabled this feature during install, you can skip this step. To check if you have a TanzuNetDependencyUpdater in your cluster, run: `kubectl get TanzuNetDependencyUpdaters -A`

The Tanzu Build Service Dependencies (Stacks, Buildpacks, Builders, etc.) are used to build applications and keep them patched.

These must be imported with the kp cli and the Dependency Descriptor (descriptor-<version>.yaml) file from the Tanzu Build Service Dependencies page:

kp import -f /tmp/descriptor-<version>.yaml

When importing to a registry that uses a self-signed CA certificate:

kp import -f /tmp/descriptor-<version>.yaml --registry-ca-cert-path <path-to-ca-cert>

Using the --show-changes flag will give a summary of the resource changes for the import. You will also be asked to confirm the import. Confirmation can be skipped with --force.

Successfully performing a kp import command requires that your Tanzu Network account has access to the images specified in the Dependency Descriptor file. Users can only access these images if they agree to the dependency EULAs.

Users must navigate to the following dependencies pages in Tanzu Network and accept all EULAs highlighted in yellow.

  1. Tanzu Build Service Dependencies
  2. Buildpacks for VMware Tanzu
  3. Stacks for VMware Tanzu

Note: `kp import` will fail if it cannot access the images in all of the above Tanzu Network pages.

Note: You must be logged in locally to the registry used for `IMAGE-REGISTRY` during relocation and the Tanzu Network registry `registry.pivotal.io`.

Additional Configuration

Other optional parameters can be added using the -v flag:

  • admin_users is a comma separated list of users who will be granted admin privileges on Build Service.
  • admin_groups: a comma separated list of groups that will be granted admin privileges on Build Service.
  • http_proxy: The HTTP proxy to use for network traffic.
  • https_proxy: The HTTPS proxy to use for network traffic.
  • no_proxy: A comma-separated list of hostnames, IP addresses, or IP ranges in CIDR format that should not use a proxy.

Note: When proxy server is enabled using http_proxy and/or https_proxy, traffic to the kubernetes API server will also flow through the proxy server. This is a known limitation and can be circumvented by using no_proxy to specify the kubernetes API server.

Configuring TKGI as an OIDC Provider

The authentication and authorization processes for Build Service use a combination of RBAC rules and third-party authentication, including OpenID Connect (OIDC). You may configure UAA as an OIDC provider for your TKGI deployment to provide authentication for Build Service.

To configure UAA as an OIDC provider for your TKGI deployment:

  1. Navigate to the OpsManager Installation Dashboard.

  2. Click the TKGI tile.

  3. Select UAA.

  4. Under Configure created clusters to use UAA as the OIDC provider, select Enable.

  5. Ensure the values in the UAA OIDC Groups Prefix and UAA OIDC Username Prefix fields are the same and record them. For example, "oidc:". You will need these values during the installation of Build Service.

    Note: Ensure you add a : at the end of the desired prefix.

  6. Click Save.

  7. In the OpsManager Installation Dashboard, click Review Pending Changes, then Apply Changes.

Installation to Air-Gapped Environment

Note: The TanzuNetDependencyUpdater cannot be used in air-gapped environments. Do not include Tanzu Net credentials for air-gapped installations.

Tanzu Build Service can be installed to a Kubernetes Cluster and registry that are air-gapped from external traffic.

An air-gapped environment will often use an internal registry with a self-signed CA certificate and you will need access to this CA certificate file to install TBS.

Note: If you are using a CA certificate that is trusted (eg. Let’s Encrypt) you will not need the CA certificate file.

Relocate Images to a Registry (Air-Gapped)

This procedure relocates images from the Tanzu Network registry to an internal image registry via a local machine.

The local machine must have write access to the internal registry.

  1. Log in to the image registry where you want to store the images by running:
docker login <IMAGE-REGISTRY>

Where IMAGE-REGISTRY is the name of the image registry where you want to store the images.

  1. Log in to the Tanzu Network registry with your Tanzu Network credentials:
docker login registry.pivotal.io
  1. Copy the Tanzu Build Service bundle to your local machine as a tar with the Carvel tool imgpkg by running:
imgpkg copy -b registry.pivotal.io/build-service/bundle:<TBS-VERSION> --to-tar=/tmp/tanzu-build-service.tar

Where TBS-VERSION is the version of Tanzu Build Service you want to install.

  1. Move the output file tanzu-build-service.tar to a machine that has access to the air-gapped environment.

  2. Unpackage the images from your local machine to the internal registry:

imgpkg copy --tar /tmp/tanzu-build-service.tar \
  --to-repo=<IMAGE-REPOSITORY>
  --registry-ca-cert-path <PATH-TO-CA>

Where:

  • IMAGE-REPOSITORY is the repository in your registry that you want to relocate images to.
  • PATH-TO-CA is the path to the registry CA certificate file.

Note: When relocating to a registry that is not Dockerhub, the IMAGE-REPOSITORY must be the IMAGE-REGISTRY appended with the destination repository for the images. For example, IMAGE-REGISTRY/build-service.

Exception: When relocating to Dockerhub, you must provide the Dockerhub repository and an image name that imgpkg will use for relocation. For example, my-dockerhub-account/build-service.

For example:

  • Dockerhub imgpkg copy --tar /tmp/tanzu-build-service.tar --to-repo=my-dockerhub-account/build-service --registry-ca-cert-path ca.crt
  • GCR imgpkg copy --tar /tmp/tanzu-build-service.tar --to-repo=gcr.io/my-project/build-service --registry-ca-cert-path ca.crt
  • Artifactory imgpkg copy --tar /tmp/tanzu-build-service.tar --to-repo=artifactory.com/my-project/build-service --registry-ca-cert-path ca.crt
  • Harbor imgpkg copy --tar /tmp/tanzu-build-service.tar --to-repo=harbor.io/my-project/build-service --registry-ca-cert-path ca.crt

Installing (Air-Gapped)

Note: The TanzuNetDependencyUpdater cannot be used in air-gapped environments. Do not include Tanzu Net credentials for air-gapped installations.

Once the images have been relocated, installation is the same as a regular install.

  1. Pull the Tanzu Build Service bundle image locally using imgpkg:
imgpkg pull -b "<IMAGE-REPOSITORY>:<TBS-VERSION>" -o /tmp/bundle

Where TBS-VERSION and IMAGE-REPOSITORY are the same values used during relocation.

  1. Use the Carvel tools kapp, ytt, and kbld to install Build Service and define the required Build Service parameters by running:
ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -f <PATH-TO-CA> \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

Where:

  • PATH-TO-CA is the path to the registry root CA. This CA is required to enable Build Service to interact with internally deployed registries. This is the CA that was used while deploying the registry.
  • IMAGE-REPOSITORY is the image repository where Tanzu Build Service images exist.

    Note: This is identical to the IMAGE-REPOSITORY argument provided during imgpkg relocation command.

    Exception: When using Dockerhub as your registry target, only use your DockerHub account for this value. For example, my-dockerhub-account (without /build-service). Otherwise, you will encounter an error similar to: Error: invalid credentials, ensure registry credentials for 'index.docker.io/my-dockerhub-account/build-service/tanzu-buildpacks_go' are available locally

  • REGISTRY-USERNAME is the username you use to access the registry. gcr.io expects _json_key as the username when using JSON key file authentication.
  • REGISTRY-PASSWORD is the password you use to access the registry.

    Note: Managing Secrets for more information about how the registry username and password are used in Tanzu Build Service.

Additional Configuration

Other optional parameters can be added using the -v flag:

  • admin_users is a comma separated list of users who will be granted admin privileges on Build Service.
  • admin_groups: a comma separated list of groups that will be granted admin privileges on Build Service.

Import Tanzu Build Service Dependencies (Air-Gapped)

The Tanzu Build Service Dependencies (Stacks, Buildpacks, Builders, etc.) are used to build applications and keep them patched.

These must be imported with the kp cli and the Dependency Descriptor (descriptor-<version>.yaml) file from the Tanzu Build Service Dependencies page.

Relocate Tanzu Build Service Dependency Images (Air-Gapped)

To import these dependencies into an air-gapped environment, they must first be relocated to the internal registry. Use kbld to perform this relocation (not imgpkg):

  1. Download the dependency images locally:
kbld package -f descriptor-<version>.yaml \
  --output /tmp/packaged-dependencies.tar

Note: You must be logged in locally to the Tanzu Network registry.

  1. Move the output file packaged-dependencies.tar to a machine that has access to the air-gapped environment.

  2. Upload the dependency images to the Tanzu Build Service registry:

kbld unpackage -f descriptor-<version>.yaml \
  --input /tmp/packaged-dependencies.tar \
  --repository <IMAGE-REPOSITORY> \
  --lock-output /tmp/dependencies-relocated.lock \
  --registry-ca-cert-path <PATH-TO-CA>

Where:

  • IMAGE-REPOSITORY is the internal image repository where dependency images will be relocated.
  • PATH-TO-CA is the path to the registry CA certificate file.

Note: You must be logged in locally to the registry used for `IMAGE-REGISTRY`.

Import Tanzu Build Service Dependency Resources (Air-Gapped)

After the dependency images are uploaded to the internal registry, you can successfully import these images and create the corresponding Tanzu Build Service resources.

Use the following command with kbld and the kp CLI:

kbld -f descriptor-<version>.yaml -f /tmp/dependencies-relocated.lock | kp import -f - --registry-ca-cert-path <path-to-ca-cert>

Verify Installation

Verify your Build Service installation by first targeting the cluster Build Service has been installed on.

To verify your Build Service installation:

  1. Download the kp binary from the Tanzu Build Service page on Tanzu Network.

  2. List the cluster builders available in your installation:

kp clusterbuilder list

You should see an output that looks as follows:

NAME       READY    STACK                          IMAGE
base       true     io.buildpacks.stacks.bionic    <image@sha256:digest>
default    true     io.buildpacks.stacks.bionic    <image@sha256:digest>
full       true     io.buildpacks.stacks.bionic    <image@sha256:digest>
tiny       true     io.paketo.stacks.tiny          <image@sha256:digest>

Upgrading Tanzu Build Service

To upgrade Tanzu Build Service to a newer version, run the same commands as installation. Re-importing dependencies is not required for upgrading TBS.

  1. Relocate the images with imgpkg:
imgpkg copy -b "registry.pivotal.io/build-service/bundle:<TBS-VERSION>" --to-repo <IMAGE-REPOSITORY>
  1. Pull the Tanzu Build Service bundle image locally using imgpkg:
imgpkg pull -b "<IMAGE-REPOSITORY>:<TBS-VERSION>" -o /tmp/bundle
  1. Run the ytt/kapp commands to install:

Tanzu Build Service 1.2 ships with a dependency updater that can update ClusterStacks, ClusterStores, ClusterBuilders, and the CNB Lifecycle from TanzuNet automatically. Enabling this feature will keep Images up to date with the latest security patches and fixes. To enable this feature, pass in your TanzuNet credentials when running the install command below:

ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    -v tanzunet_username='<TANZUNET-USERNAME>' \
    -v tanzunet_password='<TANZUNET-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

You can check the status of the DependencyUpdater by running kubectl -n build-service get TanzuNetDependencyUpdater dependency-updater -o yaml

Alternatively, if you prefer to manage dependencies yourself, simply leave the credentials out of the install.

ytt -f /tmp/bundle/values.yaml \
    -f /tmp/bundle/config/ \
    -v docker_repository='<IMAGE-REPOSITORY>' \
    -v docker_username='<REGISTRY-USERNAME>' \
    -v docker_password='<REGISTRY-PASSWORD>' \
    | kbld -f /tmp/bundle/.imgpkg/images.yml -f- \
    | kapp deploy -a tanzu-build-service -f- -y

Uninstalling Tanzu Build Service

To uninstall Tanzu Build Service simply run the following kapp command:

kapp delete -a tanzu-build-service

Note: All Tanzu Build Service resources will be deleted. Registry images created by TBS will not be deleted.

Updating Build Service Dependencies

Note: If you enabled the TanzuNetDependencyUpdater during install (This can be verified by running `kubectl get TanzuNetDependencyUpdater -A` you do not need to do anything to manage your TBS dependencies

Use the following documentation to keep applications patched and up-to-date with Tanzu Build Service:

To keep dependencies up-to-date, see Updating Build Service Dependencies

To manage Stacks, see Managing Stacks

To manage Buildpack Stores, see Managing Stores

Ensuring Access to Cluster Builders

In order to use Cluster Builders, such as the ones installed with Tanzu Build Service, we suggest to install Tanzu Build Service to a repository that is accessible by the nodes in the kubernetes cluster without credentials.

If this is not desired, see When to use Synchronized Secrets.

Ensuring the Run Image is Readable

Build Service relies on the run-image being publicly readable or readable with the registry credentials configured in a project/namespace for the builds to be executed successfully.

The location of the run image can be identified by running the following command:

kp clusterstack status <stack-name>

If the cluster stack run image is not public, you may need to create a registry secret in any namespace where Images or Builds will be used. For more details on secrets in Tanzu Build Service, see Managing Secrets

This can be done with the kp CLI:

kp secret create my-registry-creds --registry example-registry.io --registry-user my-registry-user --namespace build-namespace

Next Steps

Visit the Managing Images and Builds page to learn how to create and manage a new image.

Kubernetes Permissions for Installation

The minimum Kubernetes RBAC permissions required to install Tanzu Build Service are as follows. This includes the namespaces required for the Kubernetes Roles:

---
apiVersion: v1
kind: Namespace
metadata:
  name: build-service
---
apiVersion: v1
kind: Namespace
metadata:
  name: kpack
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: build-service-install-cluster-role
rules:
  - apiGroups:
      - "admissionregistration.k8s.io"
    resources:
      - mutatingwebhookconfigurations
      - validatingwebhookconfigurations
    verbs:
      - '*'
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      - clusterroles
      - clusterrolebindings
    verbs:
      - '*'
  - apiGroups:
      - "apiextensions.k8s.io"
    resources:
      - customresourcedefinitions
    verbs:
      - '*'
  - apiGroups:
      - "storage.k8s.io"
    resources:
      - storageclasses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - kpack.io
    resources:
      - builds
      - builds/status
      - builds/finalizers
      - images
      - images/status
      - images/finalizers
      - builders
      - builders/status
      - clusterbuilders
      - clusterbuilders/status
      - clusterstores
      - clusterstores/status
      - clusterstacks
      - clusterstacks/status
      - sourceresolvers
      - sourceresolvers/status
    verbs:
      - '*'
  - apiGroups:
      - "projects.vmware.com"
    resources:
      - projects
    verbs:
      - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: build-service-install-role
  namespace: build-service
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - secrets
      - serviceaccounts
      - services
      - namespaces
    verbs:
      - '*'
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      - roles
      - rolebindings
    verbs:
      - '*'
  - apiGroups:
      - apps
    resources:
      - deployments
      - daemonsets
    verbs:
      - '*'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kpack-install-role
  namespace: kpack
rules:
  - apiGroups:
      - ""
    resources:
      - services
      - serviceaccounts
      - namespaces
      - secrets
      - configmaps
    verbs:
      - '*'
  - apiGroups:
      - "rbac.authorization.k8s.io"
    resources:
      - roles
      - rolebindings
    verbs:
      - '*'
  - apiGroups:
      - apps
    resources:
      - deployments
      - daemonsets
    verbs:
      - '*'

The kapp command used to install Tanzu Build Service requires access to ConfigMaps in the namespace that will be used to run kapp:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: kapp-role
  namespace: <my-kapp-namespace>
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - '*'

Where the namespace <my-kapp-namespace> must be the namespace of the Kubernetes context that kapp will be run in.