Syndesis: [camel-k] Update Operator to link service accounts if a given secret 'camel-k-pull-secret' exists

[heiko-braun]

See https://github.com/syndesisio/syndesis/issues/4900 for a description. The same mechanics need to applied by the camel -k operator the be able to pull from a terms based registry.

For camel-k, as far as I know, the builder SA needs to be linked to the pull secret as well. (See https://github.com/syndesisio/syndesis/issues/4900#issuecomment-473936723)

[heiko-braun]

@astefanutti How do these changes get into Syndesis 1.6.x? Does to require another Camel K release?

[astefanutti]

@heiko-braun if we implement the image secret linking logic in the Camel K operator, then yes it would require another Camel K release.

That being said, I wonder if that is the best approach, w.r.t. Syndesis. In Camel K, running on OpenShift, three service accounts are used:

• The Camel K operator service account (camel-k-operator)
• The s2i builder pod service account (builder)
• The integration pod service account, which can be configured in the integration CR serviceAccountName spec field

For the first one, as for the Syndesis operator, the linking has to be done outside the operator code, for it to be able to run.

For the third one, the Syndesis Camel K publish handler could specify a service account in the integration spec being published, which service account would have been previously linked to the image secret consistently with the other service accounts managed by Syndesis (knowing it operates with Camel K as backend for integration runtime).

For the second one, it is the same service account being configured by the Syndesis operator. If that were to be made configurable in Camel K, that would fall into the same pattern as for the integration service account, as describe above.

From an operation standpoint, it would allow to have a single secret (syndesis-pull-secret) to be used for Syndesis and Camel K pods consistently.

If we choose that implementation, it will require to set the service account integration CR spec field from the Syndesis Camel K publish handler, link that service account to the secret in the Syndesis operator, and add a configuration parameter if we want it to be configurable. The corollary advantage is that it won't require another Camel K release.

WDYT?

/cc @lburgazzoli @nicolaferraro

[valdar]

@astefanutti +1, with the added benefit of not coupling camel-k to ocp/syndesis details.

[lburgazzoli]

+1 to set the service account integration CR

[astefanutti]

@heiko-braun unless you have any objections, I'll implement that strategy.

[heiko-braun]

sounds good

[astefanutti]

As I've started implemented it, I've come to realise that:

• The integration pods only pull local images and do not require image pull secret to be linked to their service account. This is already the case for the standard publisher, so it would make sense to keep the Camel K aligned
• The Syndesis operator is not aware of the Camel K option. While it is possible to check for the Camel CRD as a simple heuristic, it would be better to either:
  
  
  
  • Pass the camel-k option to the operator deployment
  
  
  • Or add a spec field to the syndesis CR to specify the backend
  
  
• The Syndesis operator does not manage the installation of the Camel K operator, which is done in the install script. I think this is an issue as the deploying the operator should be enough to perform the whole Syndesis install, as tool like OLM mandates it and may block #4150.

I would suggest to ask QE to validate Syndesis with Camel K works against a registry requiring authentication, closing that issue.

Then follow-up on the larger issue of the Camel K operator installation and the Syndesis operator vs. install script issue.

[heiko-braun]

Ok, so it sounds as if we only need to make sure the inital pull secret for camel k in the installation scripts?

[astefanutti]

Your understanding is correct, to be validated by QE.

[avano]

The camel-k-jvm uses fabric8/s2i-java:3.0-java8 and then the integration uses some internal reference: 172.30.1.1:5000/syndesis/camel-k-jvm:112936.

The question is if the fabric8/s2i-java:3.0-java8 will be changed in productized version to something from redhat registry or not

[astefanutti]

@avano I would expect the pod for the s2i build of the integration context to be using the builder service account by default, which is already linked by the syndesis operator. Isn't that the case? I'll double check on my side too.

[astefanutti]

@avano, I've just checked with:

$ kubectl get pod camel-k-jvm-1-build -o jsonpath="{.spec.serviceAccount}"
builder

[avano]

ah yes, I didn't take that into account while writing the comment :-) so
everything should be ok and the only necessary thing is to link the
operator sa with the secret

On Tue, Mar 26, 2019, 15:27 Antonin Stefanutti [e-mail]
wrote:

@avano https://github.com/avano, I've just checked with:

$ kubectl get pod camel-k-jvm-1-build -o jsonpath="{.spec.serviceAccount}"
builder

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/syndesisio/syndesis/issues/4945#issuecomment-476671286,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGwNAMZJdIeszePQg3idwTBcrBi0Yxelks5vai5igaJpZM4b6FUP
.

[avano]

@heiko-braun what to do with this issue then? The only necessary change would be in fuse-online-install

[heiko-braun]

@avano lets check with @lgarciaaco , maybe he did the changes alreday

[heiko-braun]

@lgarciaaco are the changes for camel k in place in fuse-online-install? @avano if i understnd you correctly, this issue can be closed, but we need to ensure that the camel k operator SA is linked to the pull secret?

[avano]

@heiko-braun exactly

[lgarciaaco]

@heiko-braun yes, I think this can be closed

[avano]

@lgarciaaco please backport https://github.com/syndesisio/fuse-online-install/pull/71 to 1.6.xbranch in fuse-online-install