Cross-namespace service binding

[baijum]

Under the Service Binding section, the second paragraph ends like this:

Cross-namespace service binding SHOULD be secured appropriately by the implementor to prevent attacks like privilege escalation and secret enumeration.

But I don't see a provision in the ServiceBinding schema to specify the namespace for the service. Based on the above statement, I expected an optional attribute to specify the namespace.

Here is a stripped-down version of schema with namespace attribute:

apiVersion: service.binding/v1alpha2
kind: ServiceBinding
...
spec:
...
  service:              # Provisioned Service resource ObjectReference-like
    apiVersion:         # string
    kind:               # string
    name:               # string
    namespace:          # string, optional
...

[scothis]

Background https://github.com/k8s-service-bindings/spec/pull/48/files#r434476027

[scothis]

tl;dr cross-namespace bindings opens a number of thorny security questions that we're not in a position to answer. So the shape of the resource intentionally does not include a namespace field. An extension that wants to add namespace support would need to do it via an annotation, or ideally a totally different resource. This wording is a warning to implementors that if they bite off cross-namespace binding, these are problems they need to answer.

[navidsh]

Discussed this issue during the interlock. To add clarification around this, the current suggestion to add some documentation around this into spec's user-facing guide tracked in https://github.com/k8s-service-bindings/spec/issues/84

[sbose78]

While users ask for cross namespace binding all the time, it's an admin nightmare so extreme caution is advised. :)

Unless we are able to implement a solid security model, we should maintain a low profile about cross-namespaced binding.

[arthurdm]

just to register my comments from the hangout today: I think it would be beneficial if the spec provided guidance on how to declare the intent to bind to a provisioned service that resides in another particular namespace. The implementation details on how that gets carried out, including the decision if that's allowed or not, would be up to individual implementations and their security configuration.

I definitely agree that the idea of "how to handle cross namespace Secrets" is a bigger k8s issue, and right now everyone is handling it different. But would be nice if the way you request this functionality is consistent.

[sbose78]

Update: Based on a very recent customer conversation, I can say that support for cross-namespace is not only desired but needed :)

[nebhale]

Better handled by an orthogonal controller.