An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html
A mechanism very similar to AWS instance profiles is Managed Service Identity (MSI) for Azure, which was announced in September 2017, though at the time of this writing, it is still in preview. I didn't try it out yet, but it does work the same way as instance profiles on AWS do, by automatically authenticating the VM to a meta-data service and allowing you to query for additional credentials without having to hardcode it into your code or image.
Azure also supports IAM.
Microsoft Azure identity and access management solutions help IT protect access to applications and
resources across the corporate data center and into the cloud. This enables additional levels of validation,
such as multifactor authentication and conditional access policies. Monitoring suspicious activity through
advanced security reporting, auditing and alerting helps mitigate potential security issues.
More detailed information please refer to this link.
Update:
You do have the ability to create Signed Access Signatures for all three Windows Azure Storage services (BLOBs, Queues and Tables) as well as for Windows Azure Service Bus Brokered Messages (Queues, Topics & Subscriptions). I have a similar question with you, maybe you could check.
I found Azure is not support instance profile like aws.
If bind a role to instance on aws, aws system will generate a temporary api access token and write to metadata server.
Aws sdk will auto fetch access token from metadata server, so a service that uses aws sdk does not need to configure sdk's access token.
But Azure's IAM and SAS(shared access signature) and metadata server, is not support mechanism like above.
Related
In the docs they give an example of how to connect to a hub by using a connection string that contains a Shared Access Signature. So far in my app, I've been able to avoid storing secrets myself by just using managed identities. Is there a way to connect to a Notification Hub with a managed identity instead of a secret? I'd rather not do my own secret management.
Referring to list of supported Azure services that support managed identities for Azure resources it seems not available for it.
You may share your feedback by creating a Feedback item and upvote it. The product group monitors this site for feedback. This is the best way to ensure you are heard and you may receive a response depending on how much they information they can currently share.
Authorization Rules (a.k.a. Access Policies) are associated with a hub and can be accessed using Azure Resource Manager calls, which I believe supports managed identity. I've thought about this but haven't tried it myself. So please report back if it works for you.
From the Azure portal I would like to programmatically and periodically create a service SAS token. Once a token has been created it should expire in one week and a new token also valid for one week will be created and so on. I was reading this article https://learn.microsoft.com/it-it/azure/storage/blobs/sas-service-create?tabs=dotnet but I am not very sure about where that code should run, in a Azure VM? I can't give internet access to the VM
The code from the article can be run from any compute service.
If that is the sole purpose of the compute resource, I would pick Logic Apps to have everything managed for you; it may have a connector to do it or you can embed some JavaScript.
Should that not be sufficient, I would use an Azure Function.
You can also use a VM if that is more suitable and restrict/block its internet access.
If you need to restrict internet access, you must be sure your blob storage is reachable, your options are:
Open whichever firewall/NSG to that storage account
Using service endpoints, service endpoint policies
Project a Private Link endpoint into the VNET from the storage
I just wrote my first app with Azure. Just a small function app calling the IoT service and suddenly it hit me - I didn't have to create any IAM role or anything. The app just worked. I tried to look up the IAM service on Azure, but found nothing. This would never fly with AWS or Google Cloud. Does Azure have any IAM-like management anywhere? If my app has a bug that allows remote server-side code execution, does it mean that the attacker will basically gain access over my entire Azure account?
Azure does have role based access control and managed service identity (identity you assign to azure services, not all of the services have that yet). If you are using connection strings (usual pattern) nothing would happen if your app gets compromised. Attacker would be able to talk to your IoT Hub (or whatever you were using).
If you are using managed service identity then the attacker could, in theory, act on behalf of that identity. So if you grant all permission to that identity - then yes. Attacker would be able to do anything.
If your application talk to Azure REST Api directly to create\modify resources and gets compromised - attacker would, in theory, have the same rights as the application.
Having said that, I dont think Azure is any way less secure then AWS or GCP. Unless you grant the app all the permissions in the world - it has none to actually manage Azure.
I have some Azure Functions that I share to my partner companies who then run the Azure Functions in their own Azure subscriptions.
Occasionally the partners run into issues and reach out to me for help. I have to instruct them to manually pull the Azure Function logs and send to me via email.
Is there anyway they can grant me permission to pull the logs from their Azure Subscription?
It depends on where you have the logs.
Either way, they can grant you RBAC permission to their resource in their subscription. Generally, they have read only access options available. All resources have the same experience for modifying RBAC (but they do differ on which policies they support). It's pretty straightforward, but this doc has more information: https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-configure
If you're using our default Storage logs, do yourself a favor and turn on App Insights because it's great. Then, if you still want to use Storage, you can get RBAC access or a SAS token and grab those logs from the Storage Account associated with the Function App. (Name should be in the AzureWebJobsDashboard setting). If you get a SAS token, you can use the Storage Explorer by choosing the SAS URI option when you connect.
If you're using App Insights, good job, you've made the right decision. You can get RBAC access to the App Insights resource and use all their great UI experience/etc. You can also get an API Key and make direct API calls against it, in the case that RBAC wouldn't work. (I would try to get RBAC access, but if that's not possible, here's a link to App Insights REST API docs: https://dev.applicationinsights.io/quickstart)
Short answer, use RBAC to get granted limited permissions (and App Insights because it's great)
I'm doing some testing with a new Cloud Service and for some reason in my certificates I'm getting a bunch of these entries
DC=Windows Azure Service Management for Extensions
All have different thumbprints. Doesn't seem to be affecting anything.. but annoying to have in the list.
What are they? How do I stop them from auto populating?
The things you could do through Azure Management Portal (like creating Cloud Services etc.) can essentially be done through Azure Service Management API. Management certificates are one way of authenticating your Service Management API requests: http://msdn.microsoft.com/en-us/library/azure/ee460782.aspx#bk_cert.
There are many reasons that these certificates are created automatically. Some of them are:
Whenever you download a publish setting file, a new management certificate is created.
If you try to connect to your cloud service VM via RDP through portal, if you don't pay attention, a new certificate is created for RDP. I'm not 100% sure but same thing happens when you update Azure Diagnostics as diagnostics is again an extension.