-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access from remote cluster #44
Comments
Hi @sebastiangaiser. Can you explain more what you mean when you say |
@katheris thank you for heading back to this issue. |
@katheris I think this is something we definitely want to support as it allows for example to secure Mirror Maker 2 connections by sharing the credentials from another cluster etc. |
Triaged on the community call of 8.8.2024: This would add a lot of value for many use cases and should be supported. We will need to investigate how the Operator SDK supports it. |
I've reached out the Operator SDK team, and although general multi cluster support is something that seems unlikely in the short term, they think being able to watch resources on other clusters would be much easier to support. For the Access Operator I think that would mean having the Strimzi cluster operator co-located with the Kafka cluster, and the Strimzi Access operator co-located with the Kafka applications. @sebastiangaiser would that fit your usecase? Java Operator SDK have opened 2493 to cover this |
@katheris That is how I would expect it regardless any limitations of the Operator SDK -> the operator runs next to the application and reads the data from the remote cluster. So I do not think this is a problem. |
@katheris yes, for me, KAO should run next to applications which are using the generated secrets in the end. Regarding the multicluster access, I had a similar problem using controller-runtime (the problem is also not solved there) and ended up with 2 reconciler:
That's how I solved that for me in the past but of course I leave the implementation open😉 |
Hey,
would it be possible to use the access-operator for reflecting user secrets from one Kubernetes cluster to another? I think this might be possible when providing a dedicated kubeconfig via cli flag.
The text was updated successfully, but these errors were encountered: