Shipa Provider Install

Providers extend Crossplane to enable infrastructure resource provisioning. In order to provision a resource, a Custom Resource Definition(CRD) needs to be registered in your Kubernetes cluster and its controller should be watching the Custom Resources those CRDs define. Provider packages contain many Custom Resource Definitions and their controllers.

For this integration, Shipa is implemented as a provider for Crossplane, implementing controllers for:

  • Application management
  • Cluster management
  • Framework management
  • Plan management
  • Role management
  • Team and user management

Installing Crossplane

Crossplane can be easily installed into any existing Kubernetes cluster using the regularly published Helm chart and the steps below:

kubectl create namespace crossplane-system
helm repo add crossplane-stable
helm repo update
helm install crossplane --namespace crossplane-system crossplane-stable/crossplane --set packageCache.sizeLimit=512Mi


Crossplane install details

You can find detailed instructions on how to install Crossplane directly from Crossplane's official documentation available here

Installing the Shipa Provider

To install the Shipa provider package, apply the following resource to the cluster where Crossplane is running:

kind: Provider
  name: provider-shipa
  package: "shipasoftware/provider-shipa:0.0.6"


Crossplane 1.6+ API Graduation

As off Crossplane 1.6, the API version of pkg.crossplane has moved from "" to "". If using Crossplane less than 1.6, use v1beta1.

You can apply the file above by using the command:

kubectl apply -f crossplane-provider-shipa.yaml

Configuring the Provider

To authenticate with the Shipa API, the provider controllers need to have access to credentials. Therefore, we use a type called Provider with information about how to authenticate to the Shipa API.

The file above configures the connection between Crossplane and the Shipa API:

apiVersion: v1
kind: Secret
  name: crossplane-secret
  namespace: crossplane-system
  endpoint: ""
  token: "your token"

type: Opaque



For Self-Managed Shipa installations, you can find your endpoint e.g the Shipa Target Address [same used by the CLI] by going to Settings -> Target Address. Got HTTPS-based targets, the port will be 8081.
If using an HTTP not HTTPS based endpoint in the crossplane-secret, the port with be 8080 e.g endpoint:

You can apply the file above using the command:

kubectl apply -f crossplane-secret.yaml


Finding your Shipa token

You can find your Shipa user token by using the following command:

shipa token show

Next, you need to create the Provider Config. You can do so using the following file:

kind: ProviderConfig
  name: default
    source: ShipaConnectionSecret
      name: crossplane-secret
      namespace: crossplane-system

You can apply the file above using the command:

kubectl apply -f crossplane-shipa-config.yaml

Your Shipa provider is now installed and ready to be used with Crossplane.


As CrossPlane is an up-and-coming paradigm, there will be changes as the CrossPlane community grows.

Resource States in ArgoCD

A known limitation as of the time of this documentation in CrossPlane is that ArgoCD does not pick up on the XRD status in CrossPlane.


CrossPlane Resource States in ArgoCD

At the time of this documentation, ArgoCD focuses on the state of the CRDs that CrossPlane creates, not the underlying resources that need to be created. For example, if there is a failure for the underlying resource, ArgoCD would show the synch as successful. This is universal for all CrossPlane providers.
Project GitHub Issue

To debug why a Shipa Object has not been successful, will need to describe the CrossPlane Kubernetes Object.

kubectl get -A
kubectl describe 

Stuck Deleting Items / Orphan Items Delete

Like in any IaC, there is the possibility of Orphan Objects. As observed, sometimes this is due to a stuck Kubernetes Finalizer. This will manifest itself differently in different CD stacks. The below steps are based on this GitHub Issue.

kubectl delete -f sample-cp-app-cname.yaml

kubectl describe

kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge