Binding to a service from a different namespace

[maleck13]

Use case

As a developer, I want to be able to provision a service into a particular namespace, but due to the heavyweight nature of the service or the desire a share its data, I want to be able to bind to that ServiceInstance from multiple namespaces. An example service would be an Authentication Service that I want many of my projects, each that live in their own namespace, to consume.

Currently I believe you need to have a service instance in the same namespace as the binding in order to create the binding. Am I correct in this? https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/controller/controller_binding.go#L190

Is this a use case that the service catalog has in mind? Is it the case that I as a developer would be expected to provision a new instance of the service and it is up to the broker implementation (perhaps via params specified by me) to decide if that is the same concrete service or whether a new one needs to be created?

[krancour]

I have wanted this from the beginning. The use case I have most frequently cited is a queue, topic, event hub, etc. where both a message producer and a message consumer must mutually bind to a single service instance. As it stands now, for this to work requires both the producer and consumer to be in the same namespace and that might not be optimal for a variety of other reasons. @pmorie has said that cross-namespace bindings may eventually be a thing, but I'm not sure what he has in mind for how to approach that or when.

[duglin]

Agreed that we need to support this usecase, but its worth noting that you can do this today by creating a UserProvided service in the 2nd namespace that contains the creds for the service instance in question. Not ideal but it should probably a work-around until we support it in a first class way.

[maleck13]

@duglin When you say UserProvided service, is there an example of this, is it what I called out in the original issue: A service instance in the 2nd namespace that the broker knows is actually a reference to the service in the 1st namespace? Or something completely different.

[duglin]

@maleck13 if you look at https://github.com/kubernetes-incubator/service-catalog/blob/master/contrib/examples/walkthrough/ups-instance.yaml it shows an example of a UPS from the walkthru. It basically allows you to provide the creds during ServiceInstance creation and then those same creds are returned during the Bind operation. So, create the instance and binding (secret) in one namespace, then create a UPS instance using the info from that secret in the 2nd namespace.

[krancour]

That's too unwieldy to be of any practical use, imo.

[krancour]

That's too unwieldy to be of any practical use, imo.

[nilebox]

It's easy to add support for binding referencing an instance from a different namespace - just add a namespace field to the instance reference structure in the binding spec. So it's not a technical limitation. The main reason for restricting access to instance within its namespace is to narrow a scope of access to prevent malicious user from stealing the credentials.

We have solved a similar problem for the other case already though. The broker object can reference an auth secret (basic auth or bearer token) from any namespace, and malicious user can register a broker stealing the auth credentials. To prevent this, we have added an admission plugin which checks that the user has access to the secret: https://github.com/kubernetes-incubator/service-catalog/tree/master/plugin/pkg/admission/broker/authsarcheck

@jpeeler @pmorie can we do the same for bindings - admission controller checking that user has access to an instance?

[maleck13]

Like this idea, wondering what perm would be required (just read or perhaps write)?

[pmorie]

I would want to vet any design for this with sig architecture. We do not currently have cross-namespace references anywhere else in Kubernetes so I think we should tread carefully here to ensure that we do something that can be repeated elsewhere.

[pmorie]

This seems like an 0.2.0 or 1.0.0 issue to me.

[lfundaro]

Hello folks,

did this go anywhere ? I am also facing this issue. Particularly for shared resource cases. A message queue might have a producer in namespace A and a consumer on namespace B.

We do not currently have cross-namespace references anywhere else in Kubernetes so I think we should tread carefully here to ensure that we do something that can be repeated elsewhere.

@pmorie: Yes, I agree with this. Nevertheless, is there any known workaround for these cases ? apart from having to put the consumer application on the same namespace where the producer lives ?

Even though resources in kubernetes do not reference each other in their declarations, k8s provides Services as an abstraction for two namespaces to communicate each other. This might sound a bit far fetched for the current context, but I am just wondering is there could be some sort of abstraction that can bridge two ServiceInstances from different namespaces.

[nilebox]

is there any known workaround for these cases.

Binding produces a Secret, which you can copy to a different namespace, e.g. using some CronJob

[lfundaro]

Binding produces a Secret, which you can copy to a different namespace, e.g. using some CronJob

Thanks for the suggestion, but I think having two different applications sharing the same service account to access a resource might be a security risk and something against best practices. Being this a workaround/hack I know it's possible to make it work, but I wonder if we can do better, meaning, not getting outside the service catalog workflow because then you lose the ability of having automatic cleanup bindings when the resource is gone or even make a deployment wait to create pods because dependencies are not ready yet (volumes, secrets, etc)

[nilebox]

@lfundaro I have previously suggested a possible solution to support secrets with different namespace: https://github.com/kubernetes-incubator/service-catalog/issues/1455#issuecomment-338511697

Without a change in Service Catalog any workaround would be some hack, as it's against the current design to access instance outside the namespace.

[lfundaro]

thanks @nilebox . So, according to your suggestion, if I understand correctly, do I need to patch the service catalog ? I think this line hints me to that https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/controller/controller_binding.go#L194. To get the ServiceInstance you would need to use not the binding's current namespace but rather the one that we specify in the binding spec ?

[nilebox]

Yes, but there are still security implications of such change. Imagine that user has permissions to create a ServiceBinding in namespace A, but doesn't have permissions to read Secrets in that namespace. Then with a new change he/she may create a namespace B, set it in the ServiceBinding spec, and steal the secret.

[lfundaro]

yeah, thanks for pointing out the security risks about it. I appreciate your help on this matter @nilebox 😄

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten