Consider managing NetworkPolicy as part of binding

[arthurbarr]

It seems like it would be really useful to be able to create a NetworkPolicy resource as part of binding to a service. Although the default NetworkPolicy is open, in secure production environments, you'd expect it to be locked down, and somebody would need to add specific policies for each application. Currently, that makes binding to a service require an additional resource.

Managing network policy as part of the Service Binding does admittedly present a security problem itself — currently the service binding only affects the client-side, and now it would affect the server-side. Being authorized to create a ServiceBinding would indirectly allow a user to adjust network policy, which may not always be what you want. Has this been discussed? Is there a way this could be done?

FYI: @arthurdm

[sbose78]

+1. This is a very valid use case.

[scothis]

I don't believe this should be part of the Service Binding spec as it requires too much knowledge of how a service is provisioned (which the spec intentionally leaves open ended).

That said, I do think this is an interesting domain to explore for implementations of the spec.

[arthurdm]

Thanks for opening this up @arthurbarr. Discussed in today's hangout. The community felt that this is a great topic for implementations to consider, but not (at this time at least) fitting with the spec.

[arthurbarr]

OK. Thanks for the feedback.

[gberche-orange]

@scothis

I don't believe this should be part of the Service Binding spec as it requires too much knowledge of how a service is provisioned (which the spec intentionally leaves open ended).

@arthurdm @nebhale

The community felt that this is a great topic for implementations to consider, but not (at this time at least) fitting with the spec.

I have listened for the related recording at 36m15s which provides additional details as I understood them:

• it would be up to implementations of the spec to create NetworkPolicy
• the spec is intentionally trying to avoid guidance in order to remain small and avoid growth

As an inspiration the open service broker api Service Binding response includes an endpoints array easing the provisionning of network policy egress rules for namespaces/pods to consume the service binding

quoted related osb api specs

> Response Field | Type | Description > -- | -- | -- > endpoints | array of Endpoint objects | The network endpoints that the Application uses to connect to the Service Instance. If present, all Service Instance endpoints that are relevant for the Application MUST be in this list, even if endpoints are not reachable or host names are not resolvable from outside the service network. > -- | -- | -- > > Response Field | Type | Description > -- | -- | -- > host* | string | A host name or a single IP address. > ports* | array of strings | A non-empty array. Each element is either a single port (for example "443") or a port range (for example "9000-9010"). > protocol | string | The protocol. Valid values are tcp, udp, or all. The default value is tcp. > > example: > > { > "credentials": { > "uri": "mysql://mysqluser:pass@mysqlhost:3306/dbname", > "username": "mysqluser", > "password": "pass", > "host": "mysqlhost", > "port": 3306, > "database": "dbname" > }, > "endpoints": [ > { > "host": "mysqlhost", > "ports:" ["3306"] > } > ] > }

This endpoints structure is helping implementations of OSB API parse the returned service binding and create necessary ACL (possibly Network policies).

I wonder whether a similar approach could be considered for k8s-service-bindings/spec?