Identity Engine - Patch Group Member Ids

[jeffwecan]

Would be handy to add / remove member (entity) IDs to an Identity group without having to perform all the read and update calls explicitly. Consider this an analog to the patch() method in the KvV2 class...

[viralpoetry]

I am doing something similar when appending multiple entities to the identity group:

def __update_group_entities(self, entity_ids, group_name):
      """
      Append list of users to an existing safe group.
      """
      logging.debug(
      'Assigning entities %s to a group within the identity backend', entity_ids)
      # check if the group name already exists
      read_response = self.admin.secrets.identity.read_group_by_name(
          name=group_name,
      )
      # recycle existing members and policies
      l_policies = read_response['data']['policies']
      create_response = self.admin.secrets.identity.create_or_update_group_by_name(
          name=group_name,
          member_entity_ids=",".join(entity_ids),
          policies=",".join(l_policies),
      )

I believe some set intersection, or other efficient operation in this patch operation will be great to have in hvac itself!

[jeffwecan]

Neat, thanks for that feedback and example @viralpoetry! For my own professional hvac use-case, I believe I landed on a similar solution. So it's good to see we have a bit of consensus there ☺.

To provide a bit more context here: personally, I've been hesitant to implement this issue for a bit to allow some more time to ruminate on the problem of colissions with concurrent (or close enough to be effectively concurrent) updates. E.g., with the KV v2 "patch" functionality within this module, we're able to leverage that secrets engine's "check and set" bit to ensure sequential requests don't stomp on each other's changes. Probably not as much of a concern within the context of this issue, but still something still worth thinking through. Ultimately I don't think that matter is a solvable problem without going upstream to Vault. So I'll try to get something along these lines implemented by the next release of this module (though if a contributor beats me to it, all the better 😉), and perhaps see if Vault itself has / needs its own issue to document this use case...