I’m not sure whether I should ask this in the vault or in the terraform forum, but given that this is terraform code, I’ll ask it here: is there any way I can set the organization (and many other details too, the organization is important though because of how kubernetes uses certificates, which I’m issuing myself using vault) in the certificate?
This is one of the examples (healthcheck-client certificate):
Subject: O = system:masters, CN = kube-etcd-healthcheck-client
In the documentation Terraform Registry I can see only the CN as a possibility.
It is possible to control the O field, but not per certificate - only at the level of the role. You could create a dedicated Terraform Registry but you’ll need to do that for each different value of organization that you need… Very messy if you need many.
I am speechless. This is becoming just… daunting. I don’t really see any logic to it. Why would anyone limit the certificate issuing like that? Especially if you think about how strict and particular about details the hashicorp developers have been about vault when it comes to security and all that. So somehow, you simply cannot use it to generate kubernetes certificates.
It is true that I haven’t seen this scenario anywhere on the internet, so I guess… that’s what I deserve.
Yes, I agree.
The Vault PKI secrets engine is rather limited in the scope it addresses. It’s OK for the basic use case of certificates for basic HTTPS applications, mostly, but beyond that it starts to show its limits.
The support for email address SANs is particularly ridiculous, as it provides no way to impose policy on what can be placed before the @ sign!
I am in a little bit of luck though thanks to you and to the utterly random fact that kubernetes uses only this “system:masters” for some certificates (and so no other organization name), which means that I don’t need to create more than two roles in total (as of yet) and I was able to adapt the certificate directives accordingly to point to their respective roles. So I kind of dodged a bullet in this phase at least.
I’m waiting for the next sobering experience though which will come in the next days.
I think it was reasonable for you to open this in the Terraform category because it wasn’t clear yet what was going on here, but from reading the rest of the discussion it seems like this ended up being about how Vault’s PKI backend works rather than how the Terraform provider interacts with it, and so I’ve moved this into the Vault category just because participants there are more likely to be familiar with the details you are discussing.