[camel-k] Update Operator to link service accounts if a given secret 'camel-k-pull-secret' exists
See original GitHub issueSee 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)
Issue Analytics
- State:
- Created 5 years ago
- Comments:19 (13 by maintainers)
Top Results From Across the Web
Pull Secret Trait - Apache Camel
The Pull Secret trait sets a pull secret on the pod, to allow Kubernetes to retrieve the container image from an external registry....
Read more >Developing and Managing Integrations Using Camel K
This chapter explains how to manage Camel K integrations on the command line and provides links to additional resources that explain how to...
Read more >camel-k installation struggles #1059 - GitHub
I'm installing using the operator procedures. The operator installs a pod (camel-k-cache) that has an unbound PVC. image. The result seems to be ......
Read more >apache/camel-k - Gitter
I have two questions about camel and kubernetes: First one, when I deploy one integration ... where i can find description what Camel-K...
Read more >Tooling for Apache Camel K by Red Hat
An instance of Apache Camel K running on a Kubernetes or an OpenShift cluster that is accessible from your system on your network....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@astefanutti +1, with the added benefit of not coupling camel-k to ocp/syndesis details.
@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:
camel-k-operator
)builder
)serviceAccountName
spec fieldFor 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