You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It does not appear that the service broker will delete unneeded policy after a service instance, org or space is deleted. This will lead to database bloat and a large number of stale entries. The documentation currently doesn't provide any guidance on how to clean this up, and the action of loading a delete policy is manual and tedious.
Just noting here that in designing this service, we did consciously choose to not delete policy because it could lead to unexpected behavior. Some examples of the kind of behavior that would be concerning:
if someone loads additional custom policy in the CONJUR_POLICY branch that may also be removed if branches are deleted on deprovision
if a host that is auto-created on bind or provision is (for some reason) used in another non-cloud foundry app, and on deprovision or unbind the host is deleted
(maybe less importantly, because this could be studied / validated) if entitlements are manually loaded in a separate policy branch (eg root) and a host or layer is later auto-deleted by the service broker, when the user attempts to reload the entitlement policy with changes it may fail when it doesn't find an included host or layer
If we have specific concerns about DAP / Conjur DB size in practice, it would be good to understand the scale that we're worried about so that we can enhance our load / performance tests to validate whether this will actually be a problem.
Describe the solution you would like
Upon restaging an app, or deleting a service instance, ask the user if they'd like to delete the associated DAP policies
Describe alternatives you have considered
At a minimum, document the manual process for cleaning up the policies. This is what we've done with VCS, which also does not support deletion, so at least we have precedence. Note that customers will frown on this approach though. Still, it is better that they know about it in advance and have the tools, cumbersome and clunky as they are, to deal with the challenge.
Additional context
Security teams tend to prefer not to leave loose ends all over the place. Conversations with auditors are challenging enough, and having to answer to why there are N number of PCF apps that have access to secrets but don't "exist" in PCF is just making the job of our champions that much harder.
Is your feature request related to a problem? Please describe.
Migrated from pivotal-cf/docs-cyberark-conjur-service-broker#23 as reported by @whip113
Describe the solution you would like
[@whip113 - do you have any proposed solutions?]
Describe alternatives you have considered
A clear and concise description of any alternative solutions or features that may be related to this that
you have considered.
Additional context
Add any other context information about the feature request here.
The text was updated successfully, but these errors were encountered: