Spire Server not listen the 8443 port by default

[anselmobattisti]

Question

After installing the spire using the tutorial

https://github.com/networkservicemesh/deployments-k8s/tree/main/examples/interdomain/three_cluster_configuration/spiffe_federation

it should be possible to access the spire server in the port 8443. however it not working.

For some reason, the file https://github.com/networkservicemesh/deployments-k8s/blob/main/examples/spire/base/server-statefulset.yaml is only opening the port 8081

          ports:
            - containerPort: 8081

however in the file https://github.com/networkservicemesh/deployments-k8s/blob/main/examples/spire/cluster1/server.conf the bundle_endpoint_url requeires the port 8443

the endpoint

            bundle_endpoint_url = "https://spire-server.spire.my.cluster2:8443"

To solve this problem i need to manually add the port 8443 to the service spire-server using a patch

---
apiVersion: v1
kind: Service
metadata:
  name: spire-server
  namespace: spire
  annotations:
    metallb.universe.tf/address-pool: my-ip-pool
spec:
  type: LoadBalancer
  selector:
    app: spire-server
  ports:
    - name: spire-server
      port: 8081
      targetPort: 8081
      protocol: TCP
    - name: bundle-endpoint
      port: 8443
      targetPort: 8443
      protocol: TCP

How about to include this soluction in this example?

Examples

In a pod inside cluster1 after execute

nc -vz spire-server.spire.my.cluster2 8443

it fails

Context

=================
CREATING CLUSTERS
=================
Creating cluster "cluster1" ...
 ✓ Ensuring node image (kindest/node:v1.31.2) 🖼
 ✓ Preparing nodes 📦 📦  
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹️ 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
 ✓ Joining worker nodes 🚜 
Set kubectl context to "kind-cluster1"
You can now use your cluster with:

kubectl cluster-info --context kind-cluster1

Have a nice day! 👋
+==============================+
| Cluster cluster1 is ready :) |
+==============================+
Creating cluster "cluster2" ...
 ✓ Ensuring node image (kindest/node:v1.31.2) 🖼
 ✓ Preparing nodes 📦 📦  
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹️ 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
 ✓ Joining worker nodes 🚜 
Set kubectl context to "kind-cluster2"
You can now use your cluster with:

kubectl cluster-info --context kind-cluster2

Thanks for using kind! 😊
+==============================+
| Cluster cluster2 is ready :) |
+==============================+
Creating cluster "cluster3" ...
 ✓ Ensuring node image (kindest/node:v1.31.2) 🖼
 ✓ Preparing nodes 📦 📦  
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹️ 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
 ✓ Joining worker nodes 🚜 
Set kubectl context to "kind-cluster3"
You can now use your cluster with:

kubectl cluster-info --context kind-cluster3

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂
+==============================+
| Cluster cluster3 is ready :) |
+==============================+

Other artifacts/Logs

Logs file from kubectl cluster-info dump:

[szvincze]

How about to include this solution in this example?

Hi @anselmobattisti,
Good catch! It was there previously but somehow I overwritten it by spire-controller-manager's service port when I uplifted spire in the examples. I am planning to do another uplift and I will not forget to include this service port for multi-cluster configuration.

[anselmobattisti]

@szvincze Thank you for your response.

I find the usage of Spire quite challenging.

It would be extremely helpful to include detailed information on how to verify whether Spire is functioning correctly in a multicluster environment.

For instance, guidance on checking if the bundles are properly configured and identifying the specific pods and ports to inspect would greatly assist in ensuring everything is working as expected.

[anselmobattisti]

For future references:

To check if the federation was correctly configured.

1 - To verify if the bundles are correctly installed in the cluster3 execute

kubectl logs spire-server-0 -n spire -c spire-server --context=kind-cluster3

And look for and entry similar to it. It means that the spire server was capable of refresh the bundle after requesting the cluster1 endpoint.

time="2024-12-03T16:45:42Z" level=info msg="Bundle refreshed" subsystem_name=bundle_client trust_domain=nsm.cluster1

2 - List the bundles in cluster3

kubectl exec spire-server-0 -n spire -c spire-server --context=kind-cluster3 -- bin/spire-server bundle list

This will show the bundles in the server. The name of the bundle must be the same of the nsm domain (i dont know if it is the correct name)

****************************************
* nsm.cluster1
****************************************
-----BEGIN CERTIFICATE-----
......
-----END CERTIFICATE-----

****************************************
* nsm.cluster2
****************************************
-----BEGIN CERTIFICATE-----
......
-----END CERTIFICATE-----

3 - Extra hint

Do not use the dynamic federation relationships in the example of NSM. Spire force the static configuration above the dynamic one.

https://spiffe.io/docs/latest/deploying/spire_server/

Note: static relationships override dynamic relationships. If you need to configure dynamic relationships, see the federation command. Static relationships are not reflected in the federation command.