Allow users to bring their own credential for deployment

[glennmusa]

Benefit/Result/Outcome
It'd be nice if I could deploy the MLZ and its configuration resources using a credential I already have.

Description
Today, we build the name for the MLZ Configuration Service Principal that is granted Contributor RBAC permissions on deployment subscriptions using the mlz_env_name argument.

Acceptance Criteria

• Allow users to specify a --username and --password for use with deployments when a --service-principal flag is supplied
• Check RBAC permissions for this SPN against the subscriptions for the deployment
• Seed the MLZ Config KeyVault with this credential
• Update mlz_objectid in .tfvars for setting Bastion jumpbox KeyVault access policies
• If a credential is provided, do not create a new one for them

[bspender]

@glennmusa - would it be within scope to bring your own service principal?
Example use case: I don't have Global Admin rights, so I have to get help from another team who needs to pre-create that SP for me. Upon completion, they provide me access to the Client id and secret, which I use to run the deployment

[glennmusa]

@bspender certainly doesn't seem unrealistic! That's a great point. Thanks for bringing it up. Looks like we could have some conversations about BYO-Deployment Credential

[glennmusa]

I imagine it's do-able by passing along to an MLZ command a --service-principal flag and supplying values for --username and --password, attempts to login to AZ cli with those values, check the correct RBAC permissions/scope for the supplied subscriptions, skipping the SP creation if all is valid, then writes those values to the .mlzconfig.

[glennmusa]

We'll need to get the object ID for setting KeyVault Access Policies when using KeyVault secrets as bastion jumpbox passwords: az ad sp show --id {the_client_id_of_the_service_principal} --query objectId --output tsv