This topic describes how you can deploy Supply Chain Security Tools (SCST) - Store in a multicluster setup, including installing multiple profiles such as View, Build, Run, and Iterate.
After installing the View profile, but before installing the Build profile and Run profile, you must copy some configurations from the View cluster to the Build and Run Kubernetes clusters. This topic explains how to add these configurations, which allow components in the Build and Run clusters to communicate with SCST - Store in the View cluster.
You must first install the View profile. This installation automatically creates the CA certificates and tokens necessary to talk to the CloudEvent Handler.
To deploy SCST - Store in a multicluster setup:
To copy SCST - Store CA certificates from the View cluster, you must copy the Metadata Store CA certificate and the AMR CloudEvent Handler CA certificate from the View cluster.
With your kubectl targeted at the View cluster, you can get Metadata Store’s TLS CA certificate by running:
MDS_CA_CERT=$(kubectl get secret -n metadata-store ingress-cert -o json | jq -r ".data.\"ca.crt\"")
cat <<EOF > store_ca.yaml
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
name: store-ca-cert
namespace: metadata-store-secrets
data:
ca.crt: $MDS_CA_CERT
EOF
With kubectl targeted at the View cluster, you can get the AMR CloudEvent Handler TLS CA certificate’s data by running:
CEH_CA_CERT_DATA=$(kubectl get secret -n metadata-store amr-cloudevent-handler-ingress-cert -o json | jq -r ".data.\"ca.crt\"" | base64 -d)
To copy SCST - Store tokens from the View cluster, you must copy the Metadata Store authentication token and the AMR CloudEvent Handler edit token from the View cluster.
Copy the Metadata Store authentication token into an environment variable by running:
MDS_AUTH_TOKEN=$(kubectl get secrets metadata-store-read-write-client -n metadata-store -o jsonpath="{.data.token}" | base64 -d)
You use this environment variable in the next step.
Copy the AMR CloudEvent Handler token into an environment variable by running:
CEH_EDIT_TOKEN=$(kubectl get secrets amr-cloudevent-handler-edit-token -n metadata-store -o jsonpath="{.data.token}" | base64 -d)
You use this environment variable in the next step.
After you copy the certificate and tokens apply them to the Build and Run clusters before deploying the profiles.
Build cluster:
Run cluster:
Before you deploy the Build profile, apply the Metadata Store CA certificate and Metadata Store authentication token from the earlier steps. This gives the Build profile deployment access to these values.
To apply the Metadata Store CA certificate and an authentication token:
With your kubectl targeted at the Build cluster, create a namespace for the Metadata Store CA certificate and authentication token.
kubectl create ns metadata-store-secrets
Apply the Metadata Store CA certificate store_ca.yaml
secret YAML you generated earlier.
kubectl apply -f store_ca.yaml
Create a secret to store the access token. This uses the Metadata Store MDS_AUTH_TOKEN
environment variable.
kubectl create secret generic store-auth-token \
--from-literal=auth_token=$MDS_AUTH_TOKEN -n metadata-store-secrets
The Build cluster now has a Metadata Store CA certificate named store-ca-cert
and a Metadata Store authentication token named store-auth-token
in the namespace metadata-store-secrets
.
You can apply the CloudEvent Handler CA certificate and edit the token to the Build and Run clusters. These values must be accessible during the Build and Run profile deployments.
If you already installed the Build cluster, skip to the next step. Otherwise, create a namespace for the CloudEvent Handler CA certificate and edit token by running:
kubectl create ns amr-observer-system
Update the Build profile values.yaml
file to add the following snippet. The code configures the CA certificate and endpoint. In amr.observer.cloudevent_handler.endpoint
you specify the location of the CloudEvent Handler that was deployed to the View cluster. In amr.observer.ca_cert_data
you paste the content of $CEH_CA_CERT_DATA
, which you copied earlier.
amr:
observer:
auth:
kubernetes_service_accounts:
enable: true
cloudevent_handler:
endpoint: https://amr-cloudevent-handler.<VIEW-CLUSTER-INGRESS-DOMAIN>
ca_cert_data: |
<CONTENTS OF $CEH_CA_CERT_DATA>
Create a secret to store the CloudEvent Handler edit token by running:
kubectl create secret generic amr-observer-edit-token \
--from-literal=token=$CEH_EDIT_TOKEN -n amr-observer-system
This command uses the CEH_EDIT_TOKEN
environment variable.
Repeat the earlier steps, but configure kubectl to target the Run cluster instead of the Build cluster.
The Build and Run clusters now each have a CloudEvent Handler CA certificate and edit token named amr-observer-edit-token
in the namespaces metadata-store-secrets
and amr-observer-system
. Now you are ready to deploy the Build and Run profiles.
If you came to this topic from Install multicluster Tanzu Application Platform profiles after installing the View profile, return to that topic to install the Build profile and install the Run profile.
The Build profile values.yaml
uses the secrets you created to configure the Grype scanner which talks to SCST - Store. After performing a vulnerabilities scan, the Grype scanner sends the results to SCST - Store.
For example:
...
grype:
targetImagePullSecret: "TARGET-REGISTRY-CREDENTIALS-SECRET"
metadataStore:
url: METADATA-STORE-URL-ON-VIEW-CLUSTER # Url with http / https
caSecret:
name: store-ca-cert
importFromNamespace: metadata-store-secrets # Must match with `ingress-cert.data."ca.crt"` of store on view cluster
authSecret:
name: store-auth-token # Must match with valid store token of metadata-store on view cluster
importFromNamespace: metadata-store-secrets
...
Where:
METADATA-STORE-URL-ON-VIEW-CLUSTER
is the ingress URL of SCST - Store deployed to the View cluster. For example, https://metadata-store.example.com
. See Ingress support.TARGET-REGISTRY-CREDENTIALS-SECRET
is the name of the secret that contains the credentials to pull an image from the registry for scanning.After you finish installing Tanzu Application Platform, configure developer namespaces. To prepare developer namespaces, you must export the Metadata Store secrets you created earlier to those namespaces.
Export secrets to a developer namespace by creating SecretExport
resources on the developer namespace. You must have created and populated the metadata-store-secrets
namespace. To create the SecretExport
resources, run:
cat <<EOF | kubectl apply -f -
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
name: store-ca-cert
namespace: metadata-store-secrets
spec:
toNamespaces: [DEV-NAMESPACES]
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
name: store-auth-token
namespace: metadata-store-secrets
spec:
toNamespaces: [DEV-NAMESPACES]
EOF
Where DEV-NAMESPACES
is an array of developer namespaces where the Metadata Store secrets are exported.
For information about metadata
configuration, see Cluster Specific Store Configuration.