Install SPIRE on standard OpenShift or IBM Cloud OpenShift clusters

This lesson will walk you through how to configure and install SPIRE on Red Hat OpenShift clusters.

In order to get full benefit from taking this lesson, you need to:

• Have a basic knowledge of Helm.
• Understand Ingress configuration.

In this lesson, you will:

• Install SPIRE on OpenShift clusters.

Key components

A set of Helm charts are available to simplify the installation of SPIRE. The Helm charts will accomplish the following:

• Install SPIRE CustomResourceDefinitions (CRDs) providing APIs for key constructs.
• Install core SPIRE components:
  • SPIRE Server: The core server responsible for managing workload identities.
  • OIDC Discovery Provider service: Facilitates OpenID Connect (OIDC) integration for identity verification.
  • SPIRE Agents: Deployed on each node hosting workloads. These agents play a crucial role in identity attestation

SPIRE deployment 

With the prerequisites in place, the first step is to clone the Git repository containing the SPIRE Helm charts. A specific tag (0.21.0) tag is specified to protect against future changes to the charts.

Here’s the command to clone the supported version (currently, the version 0.21.0 contains everything we need):

git clone -b spire-0.21.0 https://github.com/spiffe/helm-charts-hardened.git
cd helm-charts-hardened

Namespace for helm install

Note that our Helm deployment will use the namespace spire-mgmt for the installation only. The actual SPIRE deployment will use the namespace provided by the chart (e.g., spire-server). During the deployment, this namespace will be labeled with a privileged level. After installation is complete, it can be safely tightened back to restricted.

SPIRE is using a collection of CRDs. Deploy them first:

# deploy the required CRDs:
helm upgrade --install --create-namespace -n spire-mgmt spire-crds charts/spire-crds

With the Kubernetes APIs for SPIRE now installed, it is time to shift our focus to deploying SPIRE itself.

Custom values

In order to install the SPIRE Helm chart for our specific OpenShift environment, we will create a custom Helm values file containing the essential metadata about our deployment (name of our cluster, name of our organization, a country code, the trust domain associated with our deployment, etc.). The custom values file also specifies Ingress information that is typically used for accessing this cluster externally.

Create a custom values file, examples/production/example-my-values.yaml, with the following content:

global:
  spire:
    clusterName: test-openshift
  
spire-server:
  ca_subject:
    country: US
    organization: Red Hat
  ingress:
    enabled: true

spiffe-oidc-discovery-provider:
  enable: true
  # SPIRE Root CA is currently set to rotate every 2h
  # this means the thumbprint for OIDC needs to be updated frequently
  # the quick fix is to disable the TLS on SPIRE:
  tls:
    spire:
      enabled: false
  ingress:
    enabled: true
    # tlsSecret: tls-cert

In the above configuration, we will not be using TLS for OIDC access, due to frequently rotating SPIRE root CA.

Obtain the OpenShift application subdomain for Ingress

We will be using the OpenShift application subdomain during our deployment, so we can capture it and create an environment variable by executing the following command:

export appdomain=$(oc get cm -n openshift-config-managed  console-public -o go-template="{{ .data.consoleURL }}" | sed 's@https://@@; s/^[^.]*\.//') echo $appdomain

We can now use this variable during the installation of the SPIRE Helm charts.

Helm chart installation

One of Helm's benefits is that it can produce a different set of manifests depending on the input parameters specified. When targeting an IBM Cloud OpenShift deployment, an additional values file, examples/openshift/values-ibm-cloud.yaml, provides the necessary parameters to ensure a successful deployment to the environment. Other OpenShift environments should be able to make use of the standard installation of the chart.

There are parameters that reference $appdomain created above.

Standard OpenShift deployment

Deploy a production-level SPIRE Server, Agents, and CSI driver with Tornjak on OpenShift using the following command:

helm upgrade --install --create-namespace -n spire-mgmt spire charts/spire --set global.spire.namespaces.create=true \
--set global.openshift=true \
--set global.spire.trustDomain=$appdomain \
--set spire-server.ca_subject.common_name=$appdomain \
--set spire-server.ingress.host=spire-server.$appdomain \
--values examples/production/example-my-values.yaml \
--values examples/production/values.yaml  \
--values examples/tornjak/values.yaml   \
--values examples/tornjak/values-ingress.yaml  \
--render-subchart-notes --debug

IBM Cloud OpenShift deployment

Because IBM Cloud requires a specific configuration, as mentioned previously, install the SPIRE Server, Agents, and CSI driver with Tornjak using the following command: 

helm upgrade --install --create-namespace -n spire-mgmt spire charts/spire --set global.spire.namespaces.create=true \
--set global.openshift=true \
--set global.spire.trustDomain=$appdomain \
--set spire-server.ca_subject.common_name=$appdomain \
--set spire-server.ingress.host=spire-server.$appdomain \
--values examples/production/example-my-values.yaml \
--values examples/production/values.yaml  \
--values examples/tornjak/values.yaml   \
--values examples/tornjak/values-ingress.yaml  \
--values examples/openshift/values-ibm-cloud.yaml  \
--render-subchart-notes --debug

After a successful SPIRE deployment, you can tighten up the security level for the spire-server namespace.

kubectl label namespace "spire-server" pod-security.kubernetes.io/enforce=restricted --overwrite

Validation 

Note: This section requires the following environment variable, defined above: appdomain. 

Once you have installed the SPIRE Helm chart within the OpenShift environment, it is time to test and validate the installation. To start, we will review the available services. 

Test the SPIRE deployment elements

First, we can check if the Tornjak service is operating correctly. As mentioned earlier, Tornjak is the SPIFFE component representing a control plane for SPIRE in the form of the graphic user interface (GUI). 

1. Confirm access to the Tornjak API (back end): 

   curl https://tornjak-backend.$appdomain
   "Welcome to the Tornjak Backend!"

2. If the APIs are accessible, we can verify the Tornjak UI (a React application running in the local browser) can be accessed. Test access to Tornjak by opening the URL provided in the Tornjak-frontend route:

   oc get route -n spire-server -l=app.kubernetes.io/name=tornjak-frontend -o 
   jsonpath='https://{ .items[0].spec.host }'

3. The value should match the following URL: 

   echo "https://tornjak-frontend.$appdomain" 

4. Open a browser and point at the Tornjak URL obtained previously. 

5. Navigate to the Tornjak ServerInfo tab and capture the current trust domain.

6. Export the TRUST_DOMAIN environment variable by adding spiffe:// as a prefix, similar to the following:

   export TRUST_DOMAIN=spiffe://<Trust Domain from ServerInfo Page>

   The TRUST_DOMAIN environment variable is used while setting AWS roles and policy.

Conclusion

In this lesson, you learned how to configure and install SPIRE components on Red Hat OpenShift and IBM OpenShift clusters and successfully validate the SPIRE deployments.

Next, you will explore how to configure AWS services for the example application to access.