Closed stevetu21 closed 1 week ago
I think this is reasonable requirement in general. But the implementation would need to be different I guess. You would probably need to have something like this:
# ...
build:
resources:
requests:
memory: 128Mi
cpu: 500m
limits:
memory: 1Gi
cpu: 1000m
output:
type: docker
image: quay.io/scholzj/kafka-connect-build:latest
pushSecret: kafkaconnectbuild-pull-secret
additionalKanikoOptions:
- --log-format=json
registryCertificates:
- secretName: my-cluster-cluster-ca-cert
certificate: ca.crt
# ...
Instead of just allowing it in the additionalKanikoOptions
. That way the secret can be mounted and specified on the command line. Or alternatively have some other option to mount secrets to the builder pod. Since currently, there are no other ways to do this.
Of course, it would be fairly easy to just allow the option additionalKanikoOptions
and have you use a custom Kaniko image with the certificate added there. But that is more a hack rather than proper solution (but it would be easy to implement of course). So if that helps, it might be easier to implement.
You said it even better than I did! I completely agree, that's a better approach. Then I'd imagine that under the hood, --registry-certificate /path/to/my-cluster-cluster-ca-cert/ca.crt
is being passed to kaniko.
Then I'd imagine that under the hood, --registry-certificate /path/to/my-cluster-cluster-ca-cert/ca.crt is being passed to kaniko.
Yes, exactly => the operator then should mount the certificate into the pod into some specific path and automatically configure the option for Kaniko.
Triaged on 18.8.2022: The feature request makes sense. Bt we would need to clarify the APi changes needed for this since we will need to mount the certificates from some secrets and auto-configure Kaniko. So it is not completely trivial to implement and this should need a proposal to cover the changes to the API etc.
--registry-certificate
option is not enabled (from Strimzi 0.45). The certificates can be mounted using the additional volumes feature (in the template
sections).
Is your feature request related to a problem? Please describe. We run Harbor for our internal container registry, and it's secured using an internal-only self-signed Root CA. In general that means for most of our tools, we are often providing our CA Bundle so that we don't get TLS errors.
Describe the solution you'd like Include --registry-certificate as an allowed option in additionalKanikoOptions. I totally get that implementation of this would be nontrivial, since it's not just another behavioral option but rather involves passing a file. But it'd still be super useful!
Describe alternatives you've considered Currently, we're using
'additionalKanikoOptions': ['--skip-tls-verify', '--skip-tls-verify-pull']
as a stopgap. After all, Strimzi is still super-valuable to us!