Open find-arka opened 1 year ago
Hi @find-arka, thanks for the issue. I wouldn't say this is a bug - more of a missing feature. The root of the problem here is that this issuer does not allow users to set the TemplateArn themselves. This is a feature that we have discussed having, but have not committed resources to determine the best method to do so. I will discuss with the team.
Hello @divyansh-gupta, Thank you for the quick response! Looking forward to hearing more about the team-discussion outcomes on this.
Hi @find-arka, discussed with the team, there are several things we can do here:
We can ask cert-manager to include an optional pathLen
in their Certificate Resource API (currently unsupported https://cert-manager.io/docs/usage/certificate/) and consume that in this plugin to issue the certificate with the appropriate Private CA certificate template.
We can make this a more general feature to allow users to specifically name the Private CA template they would like to issue with. We can do this in two ways:
a. We update the Issuer Resource to take in a new optional TemplateArn
parameter. We can then apply this template to all issuances that happen through this Issuer. This has the disadvantage that users will have to make multiple Issuers if they want to issue with more than 1 type of Private CA template.
b. We talk to cert-manager and see if there is a way we can include TemplateArn as a custom API parameter in the Certificate Resource API (unlikely).
We aren't sure which is the right path forward yet, but would love to get your thoughts?
Hello @divyansh-gupta , Hope you are doing well! My sincere apologies for the late response on this. Thank you very much for your suggestions.
Had a discussion with @jmunozro , and we both felt that option 2.a sounds like the best one:
- We can make this a more general feature to allow users to specifically name the Private CA template they would like to issue with. We can do this in two ways: a. We update the Issuer Resource to take in a new optional TemplateArn parameter. We can then apply this template to all issuances that happen through this Issuer. This has the disadvantage that users will have to make multiple Issuers if they want to issue with more than 1 type of Private CA template.
Hello @divyansh-gupta , Hope you are doing well! Any thoughts on how this could be taken forward?
Hi @find-arka, we're having discussions as a team, and when we have a path forward we'll update you. If you have solutions we'll be happy to take a look at a pull request. Thanks for checking in!
Hi @find-arka, we will look into using Kubernetes annotations. With annotations, we think you can pass in the template ARN that you'd like to use. If we're right, then you can specify the a template with the path length that you need. Do you have any thoughts or feedback on our approach?
Just to add to that, the annotation would be something like:
kind: Certificate
metadata:
annotations:
acm-pca.template-arn: templateArn
@dcamzn , @divyansh-gupta Thank you for taking the discussion ahead. The annotation approach should work, but we might have to put additional validation to ensure that the generated cert has the right pathlen
constraint.
e.g. scenario:
SubordinateCACertificate_PathLen2/V1
Certificate
custom resource for a CA certificate, and using an Issuer
to use the above created Subordinate CA, end user decides to put annotation acm-pca.template-arn: SubordinateCACertificate_PathLen3/V1
pathlen: 2
Issuing cert, can we create a CA cert with pathlen: 3
? Assuming that the answer is no- We would have to put a validation corresponding to the annotation value: acm-pca.template-arn: SubordinateCACertificate_PathLen3/V1
so that accidentally users don't pass a template value which has higher path len than the Issuing cert path len.If we have to put in a validation like that, we would have to get the path len of the Issuing cert
and then compare with the requested path len of the new CA cert.
Can we do it this way?
path len of the Issuing cert
. Let's call this value "n"acm-pca.template-arn
is not present, and if the Certificate.spec.isCA
is set to true
, we generate the CA cert with a pathlen "n-1"I'm sure some other boundary conditions for this validation need to be present. What do you all think?
@find-arka thanks for the feedback and reviewing our approach! We agree with you that we need to put additional validations with this approach. We will review validation requirements and come back for your thoughts.
Describe the expected outcome
RootCACertificate/V1
SubordinateCACertificate_PathLen3/V1
pathlen:3
constraint i.e.Certificate
ofcert-manager.io/v1
). The generated CA certificate has the following constraints-Expected a CA certificate with
pathlen:2
Describe the actual outcome
The generated CA certificate had a
pathlen:0
constraint, instead of the expectedpathlen:2
constraint.Steps to reproduce
Create an EKS Cluster.
Install Cert Manager v1.10.0
helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version ${CERT_MANAGER_VERSION} \ --set installCRDs=true \ --wait
POLICY_ARN=$(aws iam create-policy \ --policy-name AWSPCAIssuerPolicyTest \ --policy-document file://AWSPCAIssuerPolicyTest.json \ --output json | jq -r '.Policy.Arn')
echo "POLICY_ARN = ${POLICY_ARN}"
cat << EOF | kubectl apply -f - apiVersion: awspca.cert-manager.io/v1beta1 kind: AWSPCAClusterIssuer metadata: name: my-cluster-issuer spec: arn: ${CA_ARN} region: ${CA_REGION} EOF
Verify:
Expected output:
my-internal-ca-cert-manager-tls-crt.pem
has the CA cert chained with the Issuer. Extract the top section from the pem file and copy it to a different file. I named itgenerated-ca-cert.pem
Subordinate CA cert has
pathlen:3
but the generated CA cert from that CA cert doesn't havepathlen:2
, instead it haspathlen:0
Relevant log output
Version
Cert Manager ->
v1.10.0
aws-privateca-issuer->v1.2.2
Kubernetes ->1.22
Amazon EKS platform version ->eks.6
Have you tried the following?
Category
Supported Workflow Broken
Severity
Severity 3