mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
234 lines
6.9 KiB
Plaintext
234 lines
6.9 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * security/zero_trust_workload_identity_manager/zero-trust-manager-spire-federation.adoc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="zero-trust-manager-federation-configuration_{context}"]
|
|
= Configuring SPIRE federation with the https_spiffe profile
|
|
|
|
[role="_abstract"]
|
|
The {zero-trust-full} includes SPIRE Federation support, allowing multiple independent SPIRE deployments to establish trust relationships. This procedure demonstrates how to configure federation using the `https_spiffe` profile, which uses SPIFFE-based TLS authentication between SPIRE servers.
|
|
|
|
|
|
.Prerequisites
|
|
|
|
* You have installed the OpenShift CLI (`oc`).
|
|
|
|
* You have installed the {zero-trust-full} on all clusters that will participate in the federation.
|
|
|
|
* You have `cluster-admin` privileges on all participating clusters.
|
|
|
|
* You have network connectivity between the clusters you intend to federate.
|
|
|
|
.Procedure
|
|
|
|
. Configure the `SpireServer` custom resource on each cluster to enable federation with the `https_spiffe` profile. The `https_spiffe` profile uses SPIFFE-based TLS authentication, where SPIRE servers authenticate to each other using their own SVIDs (SPIFFE Verifiable Identity Documents).
|
|
+
|
|
[source,yaml]
|
|
----
|
|
apiVersion: operator.openshift.io/v1alpha1
|
|
kind: SpireServer
|
|
metadata:
|
|
name: cluster
|
|
spec:
|
|
trustDomain: cluster1.example.com
|
|
federation:
|
|
bundleEndpoint:
|
|
profile: https_spiffe
|
|
refreshHint: 300
|
|
managedRoute: "true"
|
|
----
|
|
|
|
* The `trustDomain` field sets a unique trust domain for each cluster.
|
|
|
|
* The `profile` field uses the `https_spiffe` profile for SPIFFE-based TLS authentication.
|
|
|
|
* The `refreshHint` field suggests intervals (in seconds) for remote servers to refresh the trust bundle. Range: 60-3600 seconds.
|
|
|
|
* The `managedRoute` field enables automatic route creation by the Operator.
|
|
|
|
. Apply the configuration changes by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc apply -f spire-server.yaml
|
|
----
|
|
|
|
. Check the status of the SPIRE Server by entering the following command. Wait for the `Ready` status to be returned.
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get spireserver cluster -w
|
|
----
|
|
. Verify that the federation route has been created:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get route -n zero-trust-workload-identity-manager | grep federation
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME HOST/PORT PATH SERVICES PORT TERMINATION
|
|
spire-server-federation federation.apps.cluster1.example.com spire-server 8443 passthrough
|
|
----
|
|
|
|
. Fetch the trust bundle from each remote cluster's federation endpoint:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ curl -k https://federation.apps.cluster2.example.com > cluster2-bundle.json
|
|
----
|
|
+
|
|
[NOTE]
|
|
====
|
|
For `https_spiffe` profile, you might need to use `-k` flag if the certificate is not trusted by your system's CA bundle:
|
|
====
|
|
+
|
|
The response contains the trust bundle in JSON Web Key Set (JWKS) format:
|
|
+
|
|
.Example trust bundle
|
|
[source,json]
|
|
----
|
|
{
|
|
"keys": [
|
|
{
|
|
"use": "x509-svid",
|
|
"kty": "RSA",
|
|
"n": "...",
|
|
"e": "AQAB",
|
|
"x5c": ["..."]
|
|
}
|
|
],
|
|
"spiffe_sequence": 1,
|
|
"refresh_hint": 300
|
|
}
|
|
----
|
|
|
|
. Create `ClusterFederatedTrustDomain` resources for each remote trust domain.
|
|
+
|
|
.. On Cluster 1, create a resource to federate with Cluster 2:
|
|
+
|
|
[source,yaml]
|
|
----
|
|
apiVersion: spire.spiffe.io/v1alpha1
|
|
kind: ClusterFederatedTrustDomain
|
|
metadata:
|
|
name: cluster2-federation
|
|
spec:
|
|
trustDomain: cluster2.example.com
|
|
bundleEndpointURL: https://federation.apps.cluster2.example.com
|
|
bundleEndpointProfile:
|
|
type: https_spiffe
|
|
endpointSPIFFEID: spiffe://cluster2.example.com/spire/server
|
|
trustDomainBundle: |
|
|
{
|
|
"keys": [
|
|
{
|
|
"use": "x509-svid",
|
|
"kty": "RSA",
|
|
"n": "...",
|
|
"e": "AQAB",
|
|
"x5c": ["..."]
|
|
}
|
|
],
|
|
"spiffe_sequence": 1
|
|
}
|
|
----
|
|
|
|
* The `endpointSPIFFEID` field contains the SPIFFE ID of the remote SPIRE server. Required for `https_spiffe` profile to validate the remote server's identity.
|
|
|
|
* The `trustDomainBundle` contains the complete trust bundle JSON that you fetched in the previous step.
|
|
|
|
. Apply the `ClusterFederatedTrustDomain` resource by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc apply -f clusterfederatedtrustdomain.yaml
|
|
----
|
|
|
|
. Repeat steps 5-7 on each cluster for every remote cluster it should federate with. For bidirectional federation, each cluster needs a `ClusterFederatedTrustDomain` resource for every other cluster.
|
|
|
|
. Update the `SpireServer` resource on each cluster to add the `federatesWith` configuration:
|
|
+
|
|
[source,yaml]
|
|
----
|
|
apiVersion: operator.openshift.io/v1alpha1
|
|
kind: SpireServer
|
|
metadata:
|
|
name: cluster
|
|
spec:
|
|
trustDomain: cluster1.example.com
|
|
federation:
|
|
bundleEndpoint:
|
|
profile: https_spiffe
|
|
refreshHint: 300
|
|
federatesWith:
|
|
- trustDomain: cluster2.example.com
|
|
bundleEndpointUrl: https://federation.apps.cluster2.example.com
|
|
bundleEndpointProfile: https_spiffe
|
|
endpointSpiffeId: spiffe://cluster2.example.com/spire/server
|
|
- trustDomain: cluster3.example.com
|
|
bundleEndpointUrl: https://federation.apps.cluster3.example.com
|
|
bundleEndpointProfile: https_spiffe
|
|
endpointSpiffeId: spiffe://cluster3.example.com/spire/server
|
|
managedRoute: "true"
|
|
----
|
|
|
|
* The `federatesWith` field lists all remote trust domains this cluster should federate with.
|
|
|
|
. Apply the updated configuration by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc apply -f spireserver.yaml
|
|
----
|
|
|
|
.Verification
|
|
|
|
. Verify that the `ClusterFederatedTrustDomain` resources have been created by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc get clusterfederatedtrustdomains
|
|
----
|
|
+
|
|
.Example output
|
|
[source,terminal]
|
|
----
|
|
NAME TRUST DOMAIN ENDPOINT URL AGE
|
|
cluster2-federation cluster2.example.com https://federation.apps.cluster2.example.com 5m
|
|
cluster3-federation cluster3.example.com https://federation.apps.cluster3.example.com 5m
|
|
----
|
|
|
|
. Check the status of a `ClusterFederatedTrustDomain` to ensure bundle synchronization is working by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc describe clusterfederatedtrustdomain cluster2-federation
|
|
----
|
|
+
|
|
Look for successful status conditions indicating that the trust bundle has been synchronized.
|
|
|
|
. Verify that the federation endpoint is accessible by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ curl https://federation.apps.cluster1.example.com
|
|
----
|
|
+
|
|
You should receive a JSON response containing the trust bundle.
|
|
|
|
. Check the SPIRE Server logs to confirm federation is active by running the following command:
|
|
+
|
|
[source,terminal]
|
|
----
|
|
$ oc logs -n zero-trust-workload-identity-manager \
|
|
deployment/spire-server -c spire-server --tail=50
|
|
----
|
|
+
|
|
Look for log messages indicating successful bundle synchronization with federated trust domains.
|
|
|
|
|