Setup Zero-Trust

This guide will help you set up a secure, zero-trust environment in Grey Matter to achieve the following:

• Establish trust in user identities

• Enforce adaptive and risk-based policies

• Enable secure access to all apps

• Enforce transaction and data security

Grey Matter uses to enable zero-trust security. For more information about how Grey Matter uses SPIRE, see the .

Learn more about Grey Matter's approach to zero-trust security here.

Prerequisites

• Unix shell and Decipher account

• helm and kubectl installed

• A Kubernetes or OpenShift deployment of Grey Matter with SPIRE enabled

Step 1: Install

To install Grey Matter using SPIRE, verify that global.spire.enabled is true (the default) for your helm charts setup and .

Step 2: Deploy a new service

For a full walkthrough of an example service deployment in a SPIRE enabled environment, see .

To adapt an existing service deployment to enable SPIRE, add this environment variable to the sidecar container:

Then add the following to the deployment volumes:

and mount it into the sidecar container as:

This creates the Unix socket over which the sidecar will communicate with the SPIRE agent.

Step 3: Mesh configurations

There are several updates to make to the mesh configurations for a new service to enable SPIRE. The following describe updates necessary to configure ingress to the service using SPIRE, if your service also has egress actions, check out the .

Domain

If you have existing mesh configurations for this service in a non-SPIRE installation, remove any from the ingress domain object, but keep force_https to true. The domain should look like .

Listener

The of the listener object is used to configure ingress mTLS using SPIRE.

If you installed Grey Matter using the helm charts, each deployment should have a label with key greymatter.io/control and value the name of the service (see ). This value will be used to indicate the SPIFFE ID for a sidecar.

Let {service-name} be the value of the label greymatter.io/control in your service deployment. Add the following secret to your listener object:

Once this is configured, the sidecar will use its SPIFFE certificate for ingress traffic on this listener.

Edge to new service routing

The cluster created for edge to connect to the service will need a similar update for egress traffic to the new service. Remove any ssl_config on the edge-to-{service-name}-cluster and set the secret instead:

and should be configured as usual.

Step 4: Test

When you setup services to participate in the mesh, SPIFFE identities are setup for them. This means that the service will get a certificate that is made for that service. As an example of probing into data, you can use openssl to verify that it is setup to use SPIFFE.

In a kubernetes setup, you can find the ip of your deployment with kubectl describe pod {pod-id} | grep IP. Copy this ip and use openssl to check the certificate. You can use openssl from within the data container -

and then to check your service:

or

You should see from the info that the certificate chain and SAN that the certificate your service is presenting is from SPIRE.

You can also verify that SDS is working for your service by execing into its sidecar pod kubectl exec -it {pod-id} -c sidecar -- /bin/sh and running curl localhost:8001/certs. If the sidecar is configured properly, it's SPIFFE certificate will be listed there.

Questions?