strimzi / strimzi-kafka-operator

Apache Kafka® running on Kubernetes
https://strimzi.io/
Apache License 2.0
4.89k stars 1.31k forks source link

Include --registry-certificate as an allowed option in additionalKanikoOptions #6973

Closed stevetu21 closed 1 week ago

stevetu21 commented 2 years ago

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!

scholzj commented 2 years 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.

stevetu21 commented 2 years ago

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.

scholzj commented 2 years ago

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.

scholzj commented 2 years ago

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.

scholzj commented 1 week ago

--registry-certificate option is not enabled (from Strimzi 0.45). The certificates can be mounted using the additional volumes feature (in the template sections).