I tried Grant your VM access to a Resource Group in Azure Resource Manager
but it does not list any VM, althought I have plenty of VMs in my subscription:
No virtual machine managed identities found in this subscription
See screenshot below:
I suppose you have not enabled the system-assigned managed identity for your VM, navigate to your VM in the portal -> Identity -> System assigned -> turn the status on, see this link.
Note: Per my test, it seems to have some delay. If so, just use the filter with Azure AD user, group, or service principal, search your VM name, refer to the screenshot.
Related
When using Azure Managed Identity in the App Service/Functions, the endpoint and header are available as environment variables.
When using Azure Managed Identity in Virtual Machine, the endpoint is published as the Azure Instance Metadata service (IMDS) (http://169.254.169.254/metadata/identity/oauth2/token), accessible only from within the VM.
On a VM, is the endpoint set as an environment variable (MSI_ENDPOINT)?
On a VM, is there an indication whether managed identity is enabled?
Ideally, my code can simply check for that variable. Otherwise, I need to check the variable and make a call to the IMDS.
The Azure Managed Identity is different between App Service/Functions and VM. As you know, the App Service/Functions use the Managed Identity through the environment variables MSI_ENDPOINT and MSI_SECRET as it shows here.
But for VM, it does not set the environment variables, you will get the access token from a server inside the Azure and it cannot access outside. Here are ways to get the access token for the VMS.
The indication for the Managed Identity of the VM, I think you can get the VM identity property and it will show you if it enables the Managed Identity and which type is used. For example, I use the Azure CLI and it shows like this:
I want to check if AWS Security Hub integration is enabled for particular aws account ID and particular region using AWS Security Hub SDK?
For checking this, follow the below steps:
Your AWS account needs to have connector permissions (AWS-SD-Connector-Role) to target aws account
Assume role using the target account ARN (Amazon Resource Name) and get the temporary session credentials of a target account.
Now using the temporary session credentials get the security-hub object of a target account and check which all product subscriptions are enabled in it.
When we store the Service principal certificate/appKey in the VM (to access the keyvault), we could limit access to that file to just the user account running the program. Other users or accounts wouldn't have access to the secrets in keyvault.
When we use Azure Managed Service Identity to access keyvault from an IaaS VM, my understanding is that any user logged into the VM or any program running on the machine can access the keyvault secrets - is this true?
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
According to the article access Azure Key Vault, it seems this is true. If MSI is enabled, just need to invoke web request in the VM without e.g. appKey.
And if it is, doesn't that decrease the security in case one of the user accounts is compromised?
It should be, but the prerequisites of the access to the secret in the keyvault is the VM service principal was added as a role in Access control (IAM) and Access policies.
If you want to increase the security, you may need to remove the VM service principal in the Access policies, then it will not be able to access the secret, if you want to the service principal does not have the access to the keyvault at all, remove its role in Access control (IAM).
For more details, you could refer to: Secure your key vault.
Update:
From the doc #Arturo mentioned, it is the fact.
Any code running on that VM, is able to call the managed identities for Azure resources endpoint and request tokens.
I need to implement VM creation workflow such that admin creates VM for a user after verifying his request.
Currently, if admin creates the VM, it is marked as owner of this instance.
Can we either change or add another owner to the instance?
Can admin impersonate as another user to create a VM?
An admin cannot impersonate another user. However, in practice this is not the problem you might think, because access to resources in OpenStack is controlled by projects (basically, groups) rather than by individual users.
You can add the admin user to other tenants, and then set OS_PROJECT_NAME (and/or OS_PROJECT_ID) in your environment to the appropriate project when creating resources (such as servers, networks, etc).
When you create a resource as a particular project, any member of that project will have access to that resource.
Note that in earlier versions of OpenStack, projects were referred to as tenants and the correponding variables where OS_TENANT_NAME and OS_TENANT_ID.
I'm currently implementing a cache mechanisem for our site.
I want to use the SQL Cache dependancy feature.
I am running the following command in management studio and it's not working.
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "my_server_name\ASPNET"
The error I'm getting is:
Cannot find the user 'my_server_name\ASPNET', because it does not exist or you do not have permission.
I tried signing in with the admin of the specific database I'm setting the notification for, sa, and windows authentication with the machine administrator.
Also tried running management studio as administrator and still not joy.
Can someone please point me in the right direction.
Thank you!
First, it appears you are attempting to grant permissions to the account under which the site is running. In IIS 6 and IIS7 these are control by the account set on the Application Pool. That account used to be ASPNET but no longer by default. Instead, the default (starting with .NET 2.0 I believe) is NETWORK SERVICE. However, if you are using IIS 7, that has changed yet again. By default in IIS7 it uses something called the "ApplicationPoolIdentity" which is its own special credential created for each site. If SQL Server is on a different machine than the web server, you will run into another problem which is the credentials are all local to the machine.
My recommendation would be to do the following depending on your setup:
Both servers are on a domain and you want to use trusted connections:
Create a domain account and drop it into Domain Users.
On the web server, drop this account into the IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this domain account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
On the database server execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "domain name\MyIISAccount"
There may also be other Kerberos issues related to the fact that both servers on the domain and that might require creating a SPN (Service Principal Name).
Neither server is on a domain (i.e., both are member servers) and you want to use trusted connections:
Create a local account on both the web server and the database server with the same username and password. It is critical that they both have the same username and password. This technique involves using NTLM "pass-through" authentication which matches the hash created by the username and password to determine if the user is authenticated between the two desparate servers. On Windows 2008 R2, you may have to jump through a few local policy hoops to ensure that NTLM is enabled between the two servers.
Do steps #2 to #4 above with this account.
On the SQL Server, ensure that this local account has a Login and that this login maps to a User in the database. Then you would execute something like:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\AccountUsedBySite'
You want to use SQL accounts instead of a trusted connection:
In this scenario, the connection string used by the site to connect to the database will include a username and password which map to a Login on the SQL Server database which maps to a User in the database (typically put in the db_owner role to make it dbo). This
Assuming the credentials are correct, you need only execute your grant against this user:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLUserAccountUsedBySite'
Both IIS and SQL Server are on the same machine and you want to use trusted connections
Create a local user account and drop it into the Users group.
Drop this account into the local IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this local account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
In SQL Server, create a login for this account then create a user in the appropriate database for this account dropping it into the appropriate roles.
Now execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\MyIISAccount'
Try this:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [my_server_name\ASPNET]