quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.82k stars 2.69k forks source link

Allow ImagePullSecret Definition without ServiceAccount for Knative Deployment #32545

Open richardbischof opened 1 year ago

richardbischof commented 1 year ago

Description

Hello,

I want to use Quarkus with the Kubernetes Extension to Deploy to IBM Cloud Code Engine, which is basically a managed Knative. Therefore I have to build the image, push it to my private registry and then build Knative-Deployment Descriptors.

Because my image is saved in a private registry, I have to provide an ImagePullSecret. I configured in my applications.properties quarkus.knative.image-pull-secrets=ibm-container-registry

With this option I get an additional ServiceAccount generated, which is configured to use the secret.

But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3

If you point me in the right direction, I would love to solve this issue by myself and provide a patch.

Implementation ideas

If the Deployment Target is Knative, then don't create a new service account and instead set the image pull secret in the Service Object.

quarkus-bot[bot] commented 1 year ago

/cc @Sgitario (kubernetes), @geoand (knative,kubernetes), @iocanel (knative,kubernetes)

geoand commented 1 year ago

@Sgitario would you like to point @richardbischof in the right direction please?

Sgitario commented 1 year ago

But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3

I don't fully follow what you mean by this (I see both fields serviceAccountName and imagePullSecrets in the Revision spec).

Anyways, I guess you want to avoid the creation of the ServiceAccount altogether (my doubt is whether is because of Knative or because of your use case?).

At the moment, if you set the quarkus.knative.image-pull-secrets property, this ServiceAccount resource will always be created. If you want to fix yourself, here is the logic that controls the image-pull-secrets property: https://github.com/quarkusio/quarkus/blob/715ea8ba0862996220fea0d72eec3d90f1c88f4a/extensions/kubernetes/vanilla/deployment/src/main/java/io/quarkus/kubernetes/deployment/KnativeProcessor.java#L329.

From my point of view, the less magic we do, the better, so I would skip the service account creation when setting this property, but let me include @iocanel into the discussion that was who implemented this feature.

iocanel commented 1 year ago

With this option I get an additional ServiceAccount generated, which is configured to use the secret.

Can you please elaborate what you mean by additional? It sounds as if you end up with two ServiceAccount resources in your manifest?

But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3

I don't see something in the provided link that suggest that creating ServiceAccounts is not supported. So, I am thinking that I've got it completely wrong.

Let me try to these configuration options and see what the end result is, maybe then it will become clearer.

iocanel commented 1 year ago

I played a little bit with it and didn't have any issues. The steps I followed where:

1. create the secret

kubectl create secret generic my-secret --from-file=.dockerconfigjson=/home/iocanel/.docker/config.json --type=kubernetes.io/dockerconfigjson

### 2. create the app
```sh
quarkus create app hello-quarkus

3. add extensions

cd hello quarkus
quarkus ext add kubernetes
quarkus ext add container-image-docker

4 add configuration

quarkus.kubernetes.deployment-target=knative
quarkus.knative.image-pull-secrets=my-secret
quarkus.container-image.registry=docker.io

5. deploy

mvn clean package -Dquarkus.knative.deploy=true

I even experimented with adding kubernetes-client extension that also populates a ServiceAccount just to make sure we only get a single SA generated.

So, we would need more details in order to understand the problem.

richardbischof commented 1 year ago

Thank you all so far!

I want Quarkus to generate an Knative Service Definition / Revision, that references the necessary ImagePullSecret directly. Actually by now Quarkus generates an additionally ServiceAccount, that references the ImagePullSecret. Because IBM Code Engine does not allow the creation of ServiceAccounts, I can't apply the generated Manifests directly.

Hope, that this information helps. Thank you!