-1

I have few doubts in Azure:

  1. If I have 2 VMs with Managed Identity configured for each of them and if the IPs of these 2 VMs can talk to each other (i.e. NSG have a rule to allow network communication), but RBAC is configured to deny permission in ARM, will they be able to communicate? I suppose NOT, correct? In a corner scenario, If VM1 is compromised, is it correct to say that there will never be any interaction with VM2, because RBAC does not allow.
  2. Is this behavior similar to what is done with AWS IAM roles and permissions?
  3. If I assign a role to VM1 o talk to VM2 and then in VM2 i disallow access from VM1, which statement wins?

Thanks!!!

2funky
  • 1
  • 2

2 Answers2

1

If VM1 is compromised, is it correct to say that there will never be any interaction with VM2, because RBAC does not allow

Not quite, no. RBAC is completely separate to network access. The only thing linking identities with communications is that sometimes you need to allow network access if one server needs to authenticate to another using an Azure Active Directory principal. But they shouldn't be confused.

A Managed Identity is basically a computer account which resides in Azure AD, just like a computer account would exist in your standard on-premise Active Directory which is necessary to allow the computer to authenticate users who try to log on to the server / workstation. Sometimes you may have processes, such as Windows Services running in SYSTEM context (running as the computer account) which need access to network resources and access control allows you to grant or deny access using Active Directory.

If machine A has network access to machine B, and it is compromised because of a vulnerability in IIS, for example, you may have explicitly denied all permissions for machine A to machine B, but if machine B also runs the same version of IIS and machine A can connect to it then RBAC will not help.

Is this behavior similar to what is done with AWS IAM roles and permissions?

I'm no expert in AWS but I'm going to say it probably is the same behaviour, but again IAM and network access control are not the same things.

If I assign a role to VM1 o talk to VM2 and then in VM2 i disallow access from VM1, which statement wins?

Which role are you referring to? Network access is done in NSGs or Firewall, and roles transpire to permissions which affect Windows permissions in VM2 (ReFS permissions / NTFS / Windows Auth etc). The only way you could give any sort of access to VM2 from VM1 with roles is if you were to assign VM1 the "Cloud Device Administrator" role. Any assignee of this role is added to the local administrators group of all Azure AD joined machines. By default, a machine joined to Azure AD has no authorization to access another machines resources, except for maybe to enumerate shares on the computer. If you had a share on the computer which allowed the Everyone or Domain Computers access, then yes the machine could access it, but by default there are no such shares open on a Windows machine.

If you want to fully isolate the two machines then apply an NSG to both denying network access between them, but remember that if both machines have a public point of presence then you should block this too.

Architect Jamie
  • 1,621
  • 4
  • 18
0

Thanks. I agree that IAM and IP-network level are totally different things, but just because Azure is an homogeneous ecosystem, any Azure resource that can be defined in Azure-AD can also be associated with an IAM permission/Role that sits on top of the network permissions given by IP ACLs, so we have in reality double protection. So if we leave behind the VM1 to VM2 above example which is a corner case and we consider instead another example: Virtual Machine VM1 that talks to a Storage Account SA2. If VM1 is compromised, I will need both to have SA2 Role permission access like "Storage Blob Data Reader/Contributor" and IP access from VM1, in order to access data in SA2, correct? Overall I think that IAM Roles are far more granular than having IP ACLs, so extra due diligence should be put in IAM roles definitions and IPs are only at network layer to prevent ubiquitous access from the Internet.

If machine A has network access to machine B, and it is compromised because of a >vulnerability in IIS, for example, you may have explicitly denied all permissions >for machine A to machine B, but if machine B also runs the same version of IIS and >machine A can connect to it then RBAC will not help.

Regarding this example I am not totally 100% clear what you meant : yes if VMB runs the same IIS version, I could also compromise that one, but if VMB is running a newer version, then I would still need both IP and IAM (although there isnt any specific role for accessing VMs as you said).

2funky
  • 1
  • 2
  • IAM only relates to network ACLs so far as you can grant permissions to the VM to write to an NSG, but a machine does not have these permissions by default you would have to assign them, and to do that you would need to use an account which has Owner or Contributor access to the resource group in which the NSG resource is stored. Joining a VM to Azure AD does not give access to any Azure Resource Manager resources by default. – Architect Jamie Oct 28 '19 at 15:07
  • I used IIS as an example because if network access is granted between VMA and VMB then exploitation of VMB from VMA could be done without any RBAC permissions. It would be a network level exploit. – Architect Jamie Oct 28 '19 at 15:09
  • In AWS if you don't define a role/permissions with IAM, you can't do anything with any AWS object. What about Azure? it look sthat IP ACLs are enough to access a Storage Account object from a VM...? – 2funky Nov 04 '19 at 09:03