This image aims to depict the PKI setup, as it is provided by the cert- & trust-manager in the openziti controller helm chart.
I was wondering if the Intermediate CAs in there actually make sense – because as I understand it, in the internet the intermediate CAs are basically used to reduce the “blast radius” in case one of the (intermediate) CAs get compromised.
But in the case of the OpenZiti PKIs a compromise of the Root CA or Intermediate CA would result in the same situation, as there is just one Intermediate CA beneath the Root CA ?
So what I’m basically thinking is:
Why not just use the cert-manager integration for AWS PCA and issue the leaf certs for the Control Plane, Web and Edge Signer PKI directly using this integration? Then, there wouldn’t be Root CAs’ private keys nor Intermediate CAs’ private keys stored in the K8s cluster, as K8s secrets.
The only private keys that would still reside in the cluster are the ones for the Control Plane Identity Cert, the Web Identity Cert and the Edge Signer Cert.
So the amount of private keys stored as K8s secrets would be greatly reduced. Also, I would say that storing private keys in the K8s cluster (meaning the etcd DB - I know EKS can encrypt them…) is more risky, compared to have these private keys maintained by the AWS PCA )
Replacing the ctrl plane and web CAs currently managed by cert-manager with the AWS PCA integration would be significantly more secure.
The edge enrollment signer is a CA for which the Ziti controller must have the CA’s private key to issue leaf certs for edge routers and clients during enrollment. If PCA can provide an intermediate CA for this purpose that could eliminate all root CA private keys from cert-manager’s purview.
The singular intermediate CA is not essential for Ziti, no. However, this provides some flexibility for basing one or more of Ziti’s trust anchors on an existing root, e.g., Istio. The controller’s Helm chart has one such value already for this purpose,
ctrlPlane.alternativeIssuer. This is useful for replacing the root of the ctrl plane PKI with some other issuer known to cert-manager. The same pattern could easily be extended to the enrollment signer CA and web CA.
I can imagine an enhancement to the chart that allows for alternative issuers for leaf certs too. Generally, adding parameters to the chart makes sense to enable things like this as long as the defaults remain sane.
I’d support it if you want to suggest or sketch an alternative issuer option for the ctrl plane and web leaf certs in a controller chart issue.
I can absolutely do that - just right at the moment I cannot come up with the time needed.
But I will definitely be working on this within the next few weeks!