Once Crossplane [is installed](applications.md#crossplane), it must be configured for
use.
The process of configuring Crossplane includes:
1. Configuring RBAC permissions.
1. Configuring Crossplane with a cloud provider.
1. Configure managed service access.
1. Setting up Resource classes.
1. Using Auto DevOps configuration options.
1. Connect to the PostgreSQL instance.
To allow Crossplane to provision cloud services such as PostgreSQL, the cloud provider
stack must be configured with a user account. For example:
- A service account for GCP.
- An IAM user for AWS.
Important notes:
- This guide uses GCP as an example. However, the process for AWS and Azure will be
similar.
- Crossplane requires the Kubernetes cluster to be VPC native with Alias IPs enabled so
that the IP address of the pods are routable within the GCP network.
First, we need to declare some environment variables with configuration that will be used throughout this guide:
```sh
export PROJECT_ID=crossplane-playground # the GCP project where all resources reside.
export NETWORK_NAME=default # the GCP network where your GKE is provisioned.
export REGION=us-central1 # the GCP region where the GKE cluster is provisioned.
```
## Configure RBAC permissions
- For a non-GitLab managed cluster(s), ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
Manually grant GitLab's service account the ability to manage resources in the
`database.crossplane.io` API group. The Aggregated ClusterRole allows us to do that.
NOTE: **Note:**
For a non-GitLab managed cluster, ensure that the service account for the token provided can manage resources in the `database.crossplane.io` API group.
1. Save the following YAML as `crossplane-database-role.yaml`:
# this should match the name of the provider created in the above step
providerRef:
name: gcp-provider
reclaimPolicy: Delete
EOF
```
Apply the resource class configuration with the following command:
```sh
kubectl apply -f gcp-postgres-standard.yaml
```
Verify creation of the Resource class with the following command:
```sh
kubectl get cloudsqlinstanceclasses
```
The Resource Classes allow you to define classes of service for a managed service. We could create another `CloudSQLInstanceClass` which requests for a larger or a faster disk. It could also request for a specific version of the database.
## Auto DevOps Configuration Options
The Auto DevOps pipeline can be run with the following options:
The Environment variables, `AUTO_DEVOPS_POSTGRES_MANAGED` and `AUTO_DEVOPS_POSTGRES_MANAGED_CLASS_SELECTOR` need to be set to provision PostgresQL using Crossplane
Alertnatively, the following options can be overridden from the values for the helm chart.
-`postgres.managed` set to true which will select a default resource class.
The resource class needs to be marked with the annotation
`resourceclass.crossplane.io/is-default-class: "true"`. The CloudSQLInstanceClass
`cloudsqlinstancepostgresql-standard-default` will be used to satisfy the claim.
-`postgres.managed` set to `true` with `postgres.managedClassSelector`
providing the resource class to choose based on labels. In this case, the
value of `postgres.managedClassSelector.matchLabels.gitlab-ad-demo="true"`
will select the CloudSQLInstance class `cloudsqlinstancepostgresql-standard`
to satisfy the claim request.
The Auto DevOps pipeline should provision a PostgresqlInstance when it runs succesfully.
Verify creation of the PostgresQL Instance.
```sh
kubectl get postgresqlinstance
```
Sample Output: The `STATUS` field of the PostgresqlInstance transitions to `BOUND` when it is successfully provisioned.
```
NAME STATUS CLASS-KIND CLASS-NAME RESOURCE-KIND RESOURCE-NAME AGE
