Direct Secret References

This use case leverages direct references to Kubernetes Secret resources to enable developers to connect their application workloads to almost any backing service, including backing services that:

  • are running external to Tanzu Application Platform
  • do not adhere to the ProvisionedService of the Service Binding Specification for Kubernetes in GitHub.

The following example demonstrates a procedure to bind a new application on Tanzu Application Platform to an existing PostgreSQL database that exists in Azure.

Depending on your Kubernetes distribution and the backing Service you are hoping to connect to your Tanzu Application Platform workloads, there could be extra work to set up networking between the workload and the service endpoint and to obtain the credentials for the backing service. This example assumes the credentials are available and networking has been set up.

  1. Create a Kubernetes secret resource similar to the following example:

    # external-azure-db-binding-compatible.yaml
    ---
    apiVersion: v1
    kind: Secret
    metadata:
      name: external-azure-db-binding-compatible
    type: Opaque
    stringData:
      type: postgresql
      provider: azure
      host: EXAMPLE.DATABASE.AZURE.COM
      port: "5432"
      database: "EXAMPLE-DB-NAME"
      username: "USER@EXAMPLE"
      password: "PASSWORD"
    

    Kubernetes secret resources must abide by the Well-known Secret Entries specifications in GitHub. If you are planning to bind this secret to a Spring-based application workload and want to take advantage of the auto-wiring feature, this secret must also contain the properties required by Spring Cloud Bindings in GitHub.

  2. Apply the YAML file by running:

    kubectl apply -f external-azure-db-binding-compatible.yaml
    
  3. Grant sufficient RBAC permissions to Services Toolkit to be able to read the secrets specified by the class:

    # stk-secret-reader.yaml
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: stk-secret-reader
      labels:
        servicebinding.io/controller: "true"
    rules:
    - apiGroups:
      - ""
      resources:
      - secrets
      verbs:
      - get
      - list
      - watch
    
  4. Apply your changes by running:

    kubectl apply -f stk-secret-reader.yaml
    
  5. Create a claim for the newly created secret by running:

    tanzu service claim create external-azure-db-claim \
      --resource-name external-azure-db-binding-compatible \
      --resource-kind Secret \
      --resource-api-version v1
    
  6. Obtain the claim reference of the claim by running:

    tanzu service claim list -o wide
    

    Expect to see the following output:

    NAME                     READY  REASON  CLAIM REF
    external-azure-db-claim  True           services.apps.tanzu.vmware.com/v1alpha1:ResourceClaim:external-azure-db-claim
    
  7. Create an application workload by running a command similar to the following example:

    Example:

    tanzu apps workload create WORKLOAD-NAME \
      --git-repo https://github.com/sample-accelerators/spring-petclinic \
      --git-branch main \
      --git-tag tap-1.2 \
      --type web \
      --label app.kubernetes.io/part-of=spring-petclinic \
      --annotation autoscaling.knative.dev/minScale=1 \
      --env SPRING_PROFILES_ACTIVE=postgres \
      --service-ref db=REFERENCE
    

    Where:

    • WORKLOAD-NAME is the name of the Application Workload. For example, pet-clinic.
    • REFERENCE is the value of the CLAIM REF for the newly created claim in the output of the last step.
check-circle-line exclamation-circle-line close-line
Scroll to top icon