Operator creates an excessive number of policy entries

[ibm]

Operator creates an excessive number of policy entries

[vazirim]

@seansund The Binding and Service objects are independent of each other. Deleting a Service object does not cause the deletion of the Binding object because there is no ownership relationship. We removed this relationship to allow another user (from Garage) to create Service and Bindings in different namespaces. Having the ownership relationship would have taken care of deleting the Binding when the Service is deleted. However, Kubernetes doesn't allow objects with ownership relationships to be created in different namespaces. It has its own garbage collector, which rectifies this situation at random by removing the Binding. I recognize that we have a garbage collection issue here when the Service is deleted. In this case, the Binding waits for the Service to be recreated in order to recreate its credentials. Perhaps in the cases where the Binding and Service are in the same namespace, we can add ownership relation to alleviate this issue...

The Binding controller shouldn't recreate a credential with the same name. Will look into this. Could you please send me a yaml for the Service and Binding where you see this behavior?

[vazirim]

@seansund We are going to implement a new feature to address the problem with the excessive access policies. The feature will allow users to define aliases on Binding resources as well. So when there are many Bindings with the same name in different namespaces, rather than creating a new credential for each on the service, these Bindings can simply "alias" an existing credential.

The alias would be specified in the spec on Binding as a name of a credential on the corresponding service. If this name is unique, then it will succeed (and set the ID in Binding status to that), if it is not unique then it will fail. We can also have an optional keyID field to allow the user to specify which credential to alias when there are more than one with the same name.

Please let me know asap if this addresses your issue (planning on implementing it today). Thanks!

[vazirim]

Fixed in v0.1.5