Vault Credential Injection

Create GCP Service Account

In order to provision infrastructure on GCP, you will need to create a service account with appropriate permissions. In this guide we will only provision a CloudSQL instance, so the service account will be bound to the cloudsql.admin role. The following steps will setup a GCP service account, give it the necessary permissions for Crossplane to be able to manage CloudSQL instances, and emit the service account credentials in a JSON file.

# replace this with your own gcp project id and the name of the service account
# that will be created.
PROJECT_ID=my-project
NEW_SA_NAME=test-service-account-name

# create service account
SA="${NEW_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts create $NEW_SA_NAME --project $PROJECT_ID

# enable cloud API
SERVICE="sqladmin.googleapis.com"
gcloud services enable $SERVICE --project $PROJECT_ID

# grant access to cloud API
ROLE="roles/cloudsql.admin"
gcloud projects add-iam-policy-binding --role="$ROLE" $PROJECT_ID --member "serviceAccount:$SA"

# create service account keyfile
gcloud iam service-accounts keys create creds.json --project $PROJECT_ID --iam-account $SA

You should now have valid service account credentials in creds.json.

Store Credentials in Vault

After setting up Vault, you will need to store your credentials in the [kv secrets engine].

Note: the steps below involve copying credentials into the container filesystem before storing them in Vault. You may also choose to use Vault’s HTTP API or UI by port forwarding the container to your local environment (kubectl port-forward vault-0 8200:8200).

1. Copy Credentials File into Vault Container

Copy your credentials into the container filesystem so that your can store them in Vault.

kubectl cp creds.json vault-0:/tmp/creds.json

2. Enable KV Secrets Engine

Secrets engines must be enabled before they can be used. Enable the kv-v2 secrets engine at the secret path.

kubectl exec -it vault-0 -- /bin/sh

vault secrets enable -path=secret kv-v2

3. Store GCP Credentials in KV Engine

The path of your GCP credentials is how the secret will be referenced when injecting it into the provider-gcp controller Pod.

vault kv put secret/provider-creds/gcp-default @tmp/creds.json

4. Clean Up Credentials File

You no longer need our GCP credentials file in the container filesystem, so go ahead and clean it up.

rm tmp/creds.json

Install provider-gcp

You are now ready to install provider-gcp. Crossplane provides a ControllerConfig type that allows you to customize the deployment of a provider’s controller Pod. A ControllerConfig can be created and referenced by any number of Provider objects that wish to use its configuration. In the example below, the Pod annotations indicate to the Vault mutating webhook that we want for the secret stored at secret/provider-creds/gcp-default to be injected into the container filesystem by assuming role crossplane-providers. Template formatting has been added to make sure the secret data is presented in a form that provider-gcp is expecting.

echo "apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: vault-config
spec:
  metadata:
    annotations:
      vault.hashicorp.com/agent-inject: \"true\"
      vault.hashicorp.com/role: "crossplane-providers"
      vault.hashicorp.com/agent-inject-secret-creds.txt: "secret/provider-creds/gcp-default"
      vault.hashicorp.com/agent-inject-template-creds.txt: |
        {{- with secret \"secret/provider-creds/gcp-default\" -}}
         {{ .Data.data | toJSON }}
        {{- end -}}
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp
spec:
  package: xpkg.upbound.io/crossplane-contrib/provider-gcp:v0.22.0
  controllerConfigRef:
    name: vault-config" | kubectl apply -f -

Configure provider-gcp

One provider-gcp is installed and running, you will want to create a ProviderConfig that specifies the credentials in the filesystem that should be used to provision managed resources that reference this ProviderConfig. Because the name of this ProviderConfig is default it will be used by any managed resources that don’t explicitly reference a ProviderConfig.

Note: make sure that the PROJECT_ID environment variable that was defined earlier is still set correctly.

echo "apiVersion: gcp.crossplane.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  projectID: ${PROJECT_ID}
  credentials:
    source: Filesystem
    fs:
      path: /vault/secrets/creds.txt" | kubectl apply -f -

To verify that the GCP credentials are being injected into the container run the following command:

PROVIDER_CONTROLLER_POD=$(kubectl -n crossplane-system get pod -l pkg.crossplane.io/provider=provider-gcp -o name --no-headers=true)
kubectl -n crossplane-system exec -it $PROVIDER_CONTROLLER_POD -c provider-gcp -- cat /vault/secrets/creds.txt

Provision Infrastructure

The final step is to actually provision a CloudSQLInstance. Creating the object below will result in the creation of a Cloud SQL PostgreSQL database on GCP.

echo "apiVersion: database.gcp.crossplane.io/v1beta1
kind: CloudSQLInstance
metadata:
  name: postgres-vault-demo
spec:
  forProvider:
    databaseVersion: POSTGRES_12
    region: us-central1
    settings:
      tier: db-custom-1-3840
      dataDiskType: PD_SSD
      dataDiskSizeGb: 10
  writeConnectionSecretToRef:
    namespace: crossplane-system
    name: cloudsqlpostgresql-conn" | kubectl apply -f -

You can monitor the progress of the database provisioning with the following command:

kubectl get cloudsqlinstance -w