Allows for persisting an app for the lifetime of the role

[nbutton23]

Overview

A high level description of the contribution, including: Adds the ability to persist the created application between getting credentials.

Who the change affects or is for (stakeholders)?

Consumers of role definitions who may need to persist Service Principal application objects.

What is the change?

Adds a new field to the role schema that allows the application to persist for the lifetime of the role.

Why is the change needed?

Allows for the SPN to maintain ownership of resources created by it between runs. This will be useful for another change we would like to make to allow SPNs to be assigned graphAPI permissions. Many of those permissions have something similar to the Application.ReadWrite.OwnerBy For this permission to work correctly we need to persist the app so that it still owns the resource.

How does this change affect the user experience (if at all)?

No affect for existing roles, or roles that don’t use the new field.

Design of Change

How was this change implemented?

On role creation, if persist_app is set to true, we then create a new app and bind it to the Azure roles and groups listed in the role. We then set the application_object_id on the role so that we are able to reuse the createStaticSPSecret as the lifecycle of the credentials is the same as a static app.

On role update we remove all Azure roles and group bindings, then create the new Azure role and group bindings.

On role delete we delete all Azure role bindings and group membership (best effort) then the application.

Related Issues/Pull Requests

Contributor Checklist

[x] Add relevant docs to upstream Vault repository, or sufficient reasoning why docs won’t be added yet My Docs PR Link [ ] Add output for any tests not ran in CI to the PR description (eg, acceptance tests) [ ] Backwards compatible

[hashicorp-cla]

All committers have signed the CLA.