Add TLS/mTLS support for Tornjak

[mrsabath]

This PR adds TLS and mTLS connection to Tornjak backend. It is assumed users create secret tornjak-certs prior to deploying the helm charts when TLS and/or mTLS are enabled.

Sample secret (to be documented):

kubectl -n spire-server create secret generic tornjak-certs \
--from-file=key.pem="client.key"  \
--from-file=cert.pem="client.crt" \
--from-file=rootCA.pem="CA/rootCA.crt"

# testing TLS: 
curl --cacert CA/rootCA.crt https://localhost:20000/

# testing mTLS: 
curl  --cacert CA/rootCA.crt --key client.key --cert client.crt https://localhost:30000

[kfox1111]

I know its not done yet. But some ideas for value naming.

[marcofranssen]

I think we should implement some plumbing into the chart.

E.g. allow to create the secret via the chart. Ensure there is just a single secret containing all the required certs.

That simplifies the volume mounts.

Furthermore I gave some inline feedback on the service and port. That can be much simpler by doing following

Service structure:

tornjak

• http
  • 10080
• https. only if tls/mtls enabled
  • 10443

secret for certs

tornjak-tls-secret:
ca.crt
server.crt
client.crt

Happy to pick this up in pairing session next week to further explain.

Also wondering if we should just leverage the certManager integration as contributed in the other PR.

We can sign these certs with the same Cert-manager Issuer and CA.

[kfox1111]

@marcofranssen, I asked him to do it as two secrets before.

There are multiple reasons not exhaustive:

1. tls certificates in k8s (secret type=tls) has a particular format that includes private key and cert. Other systems such as cert-manager can automatically create certs in this form. So its important that we support it.
2. the user ca is needed for mtls. Its what the client certificate is verified against. if you use cert-manager to setup your user ca as well, its likely a completely separate ca then your service ca. This should come in through an alternate configmap/secret/the new ClusterTrustBundles type (ClusterTrustBundles (previously Trust Anchor Sets) kubernetes/enhancements#3257)

Having a create option though where the user can specify the secrets in values would be ok. That could be in this pr or in another followon feature pr?

[marcofranssen]

@marcofranssen, I asked him to do it as two secrets before.

There are multiple reasons not exhaustive:

1. tls certificates in k8s (secret type=tls) has a particular format that includes private key and cert. Other systems such as cert-manager can automatically create certs in this form. So its important that we support it.

Oh right! Very good point. Then others are just not using this type of secret. I like to use the k8s native types, so lets go with this type=tls indeed.

2. the user ca is needed for mtls. Its what the client certificate is verified against. if you use cert-manager to setup your user ca as well, its likely a completely separate ca then your service ca. This should come in through an alternate configmap/secret/the new ClusterTrustBundles type (ClusterTrustBundles (previously Trust Anchor Sets) kubernetes/enhancements#3257)

Oh then it is probably the naming that confused me. However why would the CA be different?

I would do it like this

• Cluster CA
  • server cert
  • intermediate CA
    • client cert
    • client cert
    • client cert

Isn't the root CA sufficient to build the trustchain? Now you made me doubt though :)

[kfox1111]

User CA's sometimes need to be on the internet so that users can properly get certificates for themselves. Host CA's dont need to be accessible on the internet. So keeping them separate has security benefits.You don't necessarily want a User CA to be able to issue valid Host certs from the User CA as then there is more attack surface.

There are other reasons why you may want separate chains of trust there. Hosts often need to be trusted by browsers or other services not under the sysadmin's control, so having a more traditional chain of trust makes hosts validation easier. For example, with letsencrypt. While user ca validation only happens on your own hosts, so easier to distribute to the set of machines needing that CA for client validation.

So its best to allow treating host chain of trust completely separate from user chain of trust. Some users may combine the two if they like but that should be up to them and their situation.

[marcofranssen]

User CA's sometimes need to be on the internet so that users can properly get certificates for themselves. Host CA's dont need to be accessible on the internet. So keeping them separate has security benefits.You don't necessarily want a User CA to be able to issue valid Host certs from the User CA as then there is more attack surface.

There are other reasons why you may want separate chains of trust there. Hosts often need to be trusted by browsers or other services not under the sysadmin's control, so having a more traditional chain of trust makes hosts validation easier. For example, with letsencrypt. While user ca validation only happens on your own hosts, so easier to distribute to the set of machines needing that CA for client validation.

So its best to allow treating host chain of trust completely separate from user chain of trust. Some users may combine the two if they like but that should be up to them and their situation.

So isn't that intermediate as I shown above exactly what you need to just make that available on the internet, but still have it trusted by the upstream cluster CA?

[kfox1111]

User CA's sometimes need to be on the internet so that users can properly get certificates for themselves. Host CA's dont need to be accessible on the internet. So keeping them separate has security benefits.You don't necessarily want a User CA to be able to issue valid Host certs from the User CA as then there is more attack surface.
There are other reasons why you may want separate chains of trust there. Hosts often need to be trusted by browsers or other services not under the sysadmin's control, so having a more traditional chain of trust makes hosts validation easier. For example, with letsencrypt. While user ca validation only happens on your own hosts, so easier to distribute to the set of machines needing that CA for client validation.
So its best to allow treating host chain of trust completely separate from user chain of trust. Some users may combine the two if they like but that should be up to them and their situation.

So isn't that intermediate as I shown above exactly what you need to just make that available on the internet, but still have it trusted by the upstream cluster CA?

No. If you have your own private CA for the user ca, and a public chain of trust such as letsencrypt for the hosts, it is not possible for the intermediates to be rooted at just one CA. Nor is it desirable as I explained, for security reasons. You don't want machines to trust host certs signed by the user ca so yiou can't trust the a root where there is a shared root between a user and host ca.

Also, an intermediate CA is just a way to add an additional layer of security so you don't have to expose the root ca. The intermediate CA's can have expiry times much less then the root ca's expiration date. But can issue certs much the same as the root.

The user ca must be configurable separately then any ca used for the hosts.

[kfox1111]

There are a few different options we may want to consider for the tls certs and for the user ca.....

For the host cert for each of the frontend and backend, we could support an enum with:
existing, cert-manager, values

where existing would just use the secret that exists, cert-manager would create a Certificate object to generate the tls secret, and values could create the secret from a key/cert thats specified in values

For now, this pr only supports an existing secret. Or the user can use cert-manager to create it manually. This is probably a good first step and the other options could be added in a follow up pr.

For the userCA, we have some similar options.... some combination of
existing-secret, existing-configmap, cert-manager, values

where existing-secret/configmap is preexisting objects, cert-manager would create a self signed user ca and then reference it, and values would have the ca.pem specified directly in the values and would get put in a secret.

Similar to the previous, I'd recommend the additional options be added in a follow up pr.

[kfox1111]

Some minor text things that could be changed, but could do it in a followup pr too if everyone else is happy with it the way it is.

[mrsabath]

#338 (comment)
Thank you for the comment @kfox1111
I think the most recent version already has two mount-points: https://github.com/spiffe/helm-charts/blob/tornjak-tls/charts/spire/charts/spire-server/templates/statefulset.yaml#L213-L218

[mrsabath]

@marcofranssen per your suggestion, Tornjak Helm charts currently determine automatically the Tornjak connection type, based on provided information (secrets or ConfigMaps). We will update the Tornjak code (spiffe/tornjak#268) to do this determination on the level of the Tornjak image. Once completed there, we will update these helm charts here with a new configuration format, as a follow-up PR.

[marcofranssen]

LGTM