Populate Subject Fields in Certificate

[JoshuaFurman]

I've connected cert-manager to a remote instance of Vault, where Vault is acting as my certificate issuer. However, I have some restraints generating certificates from this CA. Specifically i need to set a number of subject fields:

• subject.localities
• subject.organizationalUnits
• subject.organization
• subject.provinces
• subject.countries

There does not seem to be a way to set these for the certificates that istio-csr is attempting to create. My istio-csr deployment is failing because it cannot issue the initial certificate because Vault will not issue certificates with wildcard values for those subject fields above.

Is there anyway for me to set these values? there does not seem to be in the istio-csr helm chart...

If there is not way to do this I suppose I will have to write a custom mutating webhook to handle this but would like to avoid doing so.

Thanks.

[ThatsMrTalbot]

Based on the conversation in the bi-weekly meeting we identified that when the istio-csr starts it requests a certificate for itself:

https://github.com/cert-manager/istio-csr/blob/main/pkg/tls/tls.go#L294-L314

It does this using the same flow that Istio CSRs use, by generating a CSR PEM and then calling the Sign method.

The issue is that the istio.io/istio/security/pkg/pki/util library used to generate the CSR PEM does not allow the explicit specification of the CommonName, which is something you require set by your Vault issuer.

The ideal solution would be instead generate the CSR PEM using alternative libraries (potentially the same one cert-manager uses), that allow us to specify the CommonName, then add a flag to allow users to configure the CommonName.

We must be careful not to change other behaviours and attributes of the CSR to ensure other users are not impacted.

It would also be worth validating that Istio itself produces CSRs with a common name, or you will hit this issue all over again later.

[vijaytdh]

Just to add that this issue exists for the Google CAS Issuer too, where Google use zlint package to enforce that the subject is not empty https://cloud.google.com/certificate-authority-service/docs/rfc-compliance (see 4.1.2.6). This makes it impossible to use it with Google CAS.

Another option we looked at was Venafi but that appears to have the same issue too #184

We were looking at if we could modify the CSR using a Kyverno policy but it's pretty difficult to do that so we would probably need to develop a custom mutating webhook as @JoshuaFurman suggested but we too would like to avoid that and feel it's pretty hacky.

[vijaytdh]

It doesn't seem to be possible to even create a webhook because the private key is created in the code. It may be possible to workaround this by setting opts.Org. I had a look at the makefile but to be honest I am struggling to figure out how to build the code and image

[ThatsMrTalbot]

The Makefile setup is not great for reading and needs documentation, in general make help will print all the available commands.

make/00_mod.mk contains config for the other make "modules", for example this file configures where the image is pushed when make oci-push-manager is called

For local dev there is also the make target make test-e2e-deps-sidecars, this is used under the hood by the e2e tests but will:

• Create a local kind cluster.
• Deploy cert-manger & istio.
• Build the istio-csr image and load it into kind.
• Deploy the istio-csr helm chart using the built image.