Skip to content
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

Open
sebastiangaiser opened this issue Mar 26, 2024 · 7 comments
Open

Access from remote cluster #44

sebastiangaiser opened this issue Mar 26, 2024 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@sebastiangaiser
Copy link
Contributor

sebastiangaiser commented Mar 26, 2024

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.

@katheris
Copy link
Contributor

Hi @sebastiangaiser. Can you explain more what you mean when you say when providing a dedicated kubeconfig via cli flag? The access-operator is built on top of the Java operator SDK and as far as I understand that is not aimed at targeting multiple Kubernetes clusters. Either way, it's not possible today, is this a feature you would be interested in? If so can I ask what your usecase would be?

@sebastiangaiser
Copy link
Contributor Author

@katheris thank you for heading back to this issue.
Maybe my use case explains my issue/question/enhancement/request a bit better:
When operating e.g. 2. Kubernetes clusters, one for the Strimzi deployed Kafka and another one for the clients itself, it would be helpful to use the KAO for reflecting the KafkaUser's credentials to the clients cluster.
A way to have an authentication between these 2 cluster working would be generating a kubeconfig using a service-account. This kubeconfig could be used by the Kubernetes client library.
TBH I never used the Java operator SDK :D

@scholzj
Copy link
Member

scholzj commented Jul 16, 2024

@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.

@scholzj
Copy link
Member

scholzj commented Aug 8, 2024

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.

@katheris
Copy link
Contributor

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

@scholzj
Copy link
Member

scholzj commented Aug 13, 2024

@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.

@sebastiangaiser
Copy link
Contributor Author

@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:

  • remote reconciler which uses a Kubeconfig to access the "remote" cluster and informs the local reconciler
  • local reconciler which uses the in-cluster config (serviceaccount, role, rolebinding) and gets informed by the remote reconciler

That's how I solved that for me in the past but of course I leave the implementation open😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants