Azure Default SP Role is Contributor (Lets you manage everything except access to resources.)

Hey Team,

Regarding Azure Key Vault Usage

The command in https://github.com/mozilla/sops/blob/master/README.rst#23encrypting-using-azure-key-vault

az ad sp create-for-rbac -n my-keyvault-sp

Creates a Service Principal that has Contributor Access (Power User)

az ad sp create-for-rbac -n my-keyvault-sp
Changing "my-keyvault-sp" to a valid URI of "http://my-keyvault-sp", which is the required format used for service principal names
{
  "appId": "<APPID>",
  "displayName": "my-keyvault-sp",
  "name": "http://my-keyvault-sp",
  "password": "<PASSWORD",
  "tenant": "<TENANTID>"
}
az role assignment list --assignee <APPID> --query [].roleDefinitionName
[
  "Contributor"
]

Which allows the SP to do whatever it would like it the subscription...

Azure was unable to tell us which Read permission that the SP needed... and Vault Contributor (Azure Key Vault Power User) does not provide the needed access (403s from the API)
In order to get our team moving and provide a least permission solution, we assigned the Azure "Reader" role upon SP creation, which satisfied the IAM permission.

az ad sp create-for-rbac -n my-keyvault-sp --role="Reader"
Changing "my-keyvault-sp" to a valid URI of "http://my-keyvault-sp", which is the required format used for service principal names
{
  "appId": "<APPID>",
  "displayName": "my-keyvault-sp",
  "name": "http://my-keyvault-sp",
  "password": "<PASSWORD",
  "tenant": "<TENANTID>"
}
az role assignment list --assignee <APPID> --query [].roleDefinitionName
[
  "Reader"
]

Thanks!

Start with the Azure Key Vault instructions in README.rst at the linked “Encrypting using Azure Key Vault” section. Review the documented az ad sp create-for-rbac command and its role assignment behavior, then update the example to reflect the least-privilege role described in the issue. Done means the instructions no longer grant unnecessary Contributor access and clearly state the required role.