ingressShim doesn't supply x.509 subject fields required by our providers (TPP) policies

[mfacenet]

Is your feature request related to a problem? Please describe. We're recently converting our usage of Lets Encrypt to TPP for securing our ingresses. Our TPP has an organizational wide policy that enforces that our x.509 subject field contain our company name, address, etc, however, the ingressShim doesn't give us a way to specify that as the only annotations that are even related to those fields is the cert-manager.io/common-name annotation.

Describe the solution you'd like I can think of three different solutions that all have some validity.

1. Create annotations that set matching fields in the x509Subject
2. Create a template certificate resource that the ingressShim merges annotations/dns entries with that is user controlled.
3. Create a way to default certain values at the issuer/clusterissuer level, i.e. x509 subject values, key cipher/length, etc that are then merged in when the certificate request is generated.

Describe alternatives you've considered We've looked at disabling the organizational policy, however, we're just one team of many, we're also 4 layers deep within TPP so this becomes a significant and daunting task beyond just creating the exception that our team doesn't need to meet the x509 policy.

/kind feature

[jetstack-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle stale

[jetstack-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close. Send feedback to jetstack. /lifecycle rotten /remove-lifecycle stale

[hawksight]

You are right that the subject details are not available as an annotation. I can't comment on if / when that might be a feature.

Are you able to provide an example of the policy settings? I realise this is 4 layers down, but the issuer will only refer to one policy. In particular I am keen to know if the subject fields in the TPP policy are locked, or if they are inherited from a higher up the tree policy?

It's my understanding that cert-manager reads the policy from TPP and generates a csr that as closely matches that policy as is can. It might be helpful to see how the CSR that you can find in the CertificateRequest resource actually differs from the policy.

It sounds like either the TPP policy requires the value to be passed explicitly or that the request generated is either missing or setting those subjects fields incorrectly perhaps. Have you raised this with Venafi support?

Here are a couple example commands that might help see the differences:

# get the request from the `cr` in clusters
kubectl get cr <YOUR_CR_NAME> -o jsonpath='{.spec.request}' | base64 --decode | openssl req -text -noout -in -

# Get the policy with vcert cli (export TPP_URL and TPP_ACCESS_TOKEN to env first)
vcert getpolicy -u $TPP_URL -t $TPP_ACCESS_TOKEN -z "<YOUR_ZONE_HERE>" --verbose

[jetstack-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten. Send feedback to jetstack. /close

[jetstack-bot]

@jetstack-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten. Send feedback to jetstack. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[herzogf]

Is it possible to reopen this ticket? We are dealing with a similar situation where our company CA demands a specific set of OU/O/L/C combination. We switched back to using cert-manager Certificate objects directly but would like to just use the annotations on the ingress. Ideally there'd be annotations for each subject field of the Certificate resource but it'd also be ok to specifiy the complete subject as one annotation (translating to the literal subject feature from https://cert-manager.io/docs/release-notes/release-notes-1.9/#literal-certificate-subjects). Should I create a separate issue for this or can we just reopen this one? Thanks!