I created an Azure Policy which automatically performs actions on created resources. This in turn created a managed identity for these operations. Everything works great.
The necessary permissions for the managed identity are automatically assigned to the scope (subscription in my case). However, if you only see the permissions, you have no way of knowing what this managed identity is and why it exists. My idea would be to change the display name. Unfortunately, I don't see how.
How can I change the display name (in red) of the application? Is there a different way to make it more clear to others why this assignment exists on the given scope?
I tried changing the name via Azure CLI, but seem to have no permissions, even though I own the directory. I can change the name of other enterprise applications.
az ad sp update --id 4bf9bdf0-5a67-45a7-b580-566d63b4a652 --set appDisplayName="AzurePolicy"
Insufficient privileges to complete the operation.
My current best guess for a workaround answer would be to create a custom role which should only be used by my policy definition. I can then give it exactly the permissions it requires - and I can give the role a name. However, I would prefer a solution with less management involved, since it would also require me to create all policies instead of reusing existing ones.
Update:
As of August 2021, you can use user-assigned managed identities for Azure Policy, which can have a good name (and tags) to make things much more transparent. The name of a system-assigned managed identity is still cryptic and cannot be changed.
Related
I am trying to understand the difference between google_service_account_iam_binding and google_service_account_iam_member in the GCP terraform provider at https://www.terraform.io/docs/providers/google/r/google_service_account_iam.html.
I understand that google_service_account_iam_binding is for granting a role to a list of members whereas google_service_account_iam_member is for granting a role to a single member, however I'm not clear on what is meant by "Authoritative" and "Non-Authoritative" in these definitions:
google_service_account_iam_binding: Authoritative for a given role. Updates the IAM policy to grant a role to a list of members. Other roles within the IAM policy for the service account are preserved.
google_service_account_iam_member: Non-authoritative. Updates the IAM policy to grant a role to a new member. Other members for the role for the service account are preserved.
Can anyone elaborate for me please?
"Authoritative" means to change all related privileges, on the other hand, "non-authoritative" means not to change related privileges, only to change ones you specified.
Otherwise, you can interpret authoritative as the single source of truth, and non-authoritative as a piece of truth.
This link helps a lot.
Basically it means: if a role is bound to a set of IAM identities and you want to add more identities, authoritative one will require you to specify all the old identities again plus the new identies you wanna add otherwise any old identities you didn't specify will be unbinded from the role.
It is quite close to the idea of force push in git cause it will overwrite any existing stuff. In our case it is identity.
Non-authoritative is the opposite:
You only need to care the identity you are updating
Authoritative may remove existing configurations and destroy your project, while Non-Authoritative does not.
The consequence of using the Authoritative resource can be severely destructive. You may regret if you used them. Do not use them unless you are 100% confident that you must use Authoritative resources.
Usability improvements for *_iam_policy and *_iam_binding resources #8354
I'm sure you know by now there is a decent amount of care required when using the *_iam_policy and *_iam_binding versions of IAM resources. There are a number of "be careful!" and "note" warnings in the resources that outline some of the potential pitfalls, but there are hidden dangers as well. For example, using the google_project_iam_policy resource may inadvertently remove Google's service agents' (https://cloud.google.com/iam/docs/service-agents) IAM roles from the project. Or, the dangers of using google_storage_bucket_iam_policy and google_storage_bucket_iam_binding, which may remove the default IAM roles granted to projectViewers:, projectEditors:, and projectOwners: of the containing project.
The largest issue I encounter with people running into the above situations is that the initial terraform plan does not show that anything is being removed. While the documentation for google_project_iam_policy notes that it's best to terraform import the resource beforehand, this is in fact applicable to all *_iam_policy and *_iam_binding resources. Unfortunately this is tedious, potentially forgotten, and not something that you can abstract away in a Terraform module.
See terraform/gcp - In what use cases we have no choice but to use authoritative resources? and reported issues.
A simple example. If you run the script, what you think will happen. Do you think you can continue using your GCP project?
resource "google_service_account" "last_editor_standing" {
account_id = "last_editor_standing"
display_name = "last editor you will have after running this terraform"
}
resource "google_project_iam_binding" "last_editor_standing" {
project = "ToBeDemised"
members = [
"serviceAccount:${google_service_account.last_editor_standing.email}"
]
role = "roles/editor"
}
This will at least delete the Google APIs Service Agent which is essential to your project.
If you still think it is the type of resource to use, use at own your risk.
I am looking at way to delegate contributor / owner permissions to resource groups lifecycle based on name pattern of the group. I am having trouble finding the proper approach.
In custom role definition, there does not seem to be an easy way to assign Actions to resource type based on name pattern, while in azure policy definition i do not see a way to query user principal to determine a role of a user making an access action.
Policy is not user aware, so you will not be able to get that information and enforce it.
As a different approach, you could listen for the resource group creation events with event grid, and assign the relevant roles based on the events.
https://www.serverlessnotes.com/docs/detect-changes-in-your-azure-subscriptions-or-resource-groups-with-azure-event-grid
You could use Logic Apps or Azure Functions to achieve your result, although I am unsure how easy it will be to get Logic Apps to set role assignments on your resource groups.
You will need to give this automation process some fairly high permissions to achieve that, so be wary of that.
A little context: I'm having to migrate a project from AWS, where I'm currently using ECS, to Azure, where I'll be using AKS since their ACS (ECS equivalent) is deprecated.
This is a regular Django app, with its configuration variables being fetched from a server-config.json hosted on a private S3 bucket, the EC2 instance has the correct role with S3FullAccess,
I've been looking into reproducing that same behavior but with Azure Blob Storage instead, having achieved no success whatsoever :-(.
I tried using the Service Principal concept and adding it to the AKS Cluster with Storage Blob Data Owner roles, but that doesn't seem to work. Overall it's been quite the frustrating experience - maybe I'm just having a hard time grasping the right way to use the permissions/scopes. The fact that the AKS Cluster creates its own resource group is something unfathomable - but I've attempted attaching the policies to it as well, to no avail. I then moved onto a solution indicated by Microsoft.
I managed to bind my AKS pods with the correct User Managed Identity through their indicated solution aad-pod-identity, but I feel like I'm missing something. I assigned Storage Blob Data Owner/Contributor to the identity, but still, when I enter the pods and try to access a Blob (using the python sdk), I get a resource not found message.
Is what I'm trying to achieve possible at all? Or will I have to change to a solution using Azure Keyvault/something along those lines?
first off all, you can use AKS Engine which is more or less ACS for Kubernetes now.
As for the access to the blob storage, you dont have to use Managed Service Identity, you can just use account name\key ( which is a bit less secure, but a lot less error prone and more examples exist ). The fact that you are getting resource not found error most likely means your auth part is fine, you just dont have access to the resource, according to this storage blob contributor should be fine if you assigned it at a proper scope. For this to work 100% just give your identity contributor access at subscription level, this way its guaranteed to work.
I've found an example of using python with MSI (here). You should start with that (and grant your identity contributor access) and verify you can list resource groups. when that works making reading blobs working should be trivial.
When I create an AKS cluster using Azure portal I can see that new resource groups are created. It seems that I have no control over how they are named, especially the one with with "MC_" prefix. I also don't see an option to change its name when using ARM template.
In addition, if I create a cluster in customer's subscription, where I only have access to 1 resource group, I don't even see the newly created RG and can't manage it.
Is there a way to force deployment of all AKS components into a single resource group?
No, there is no way to force it at this point in time. As for the access, you should request access to that RG. No real workarounds.
Secondary resource group name can be inferred, I think, its something like:
MC_original-resource-group-name_aks-resource-name_location
it also creates OMS resource group (if you enable OMS) and Network Watcher (this can be disabled, btw, but its a provider setting). you have no control over that as well.
there is a not implemented yet nodeResourceGroup property: https://learn.microsoft.com/en-us/rest/api/aks/managedclusters/createorupdate#examples
EDIT: this is actually working right now, so the nodeResourceGroup property can be used. But it would still be a new resource group, so you would still need to request access to that group and using this property is not possible with the portal (so ARM Templates\pulumi\terraform)
I am trying to understand how can I run a python application inside azure container that can spin up various resources like VM, route-table inside resource group of Azure.
http://azure-sdk-for-python.readthedocs.io/en/latest/
Looks like the examples provided in azure python sdk sets authentication stuff like credentials, subscription ID, etc.
Is there a way to avoid setting up of this information by using Role Based Access Control ? What if I provide container an Contributor access to the resource group, in that case, would i able to avoid setting up authentication variables and still achieve creating resources or atleast read/access resources in resource group ?
No, how do you think that would work? In order to be able to create\read\modify resources you need permissions (else anyone would be able to do that). There is no way to do that without some sort of Auth.