I set up a Storage Container (Blob) and a Role Assignement (Storage Account Contributor) to a App Registration with a client Secret-> so I can query the blob files in a runbook as a service principal. So far so fine. App Registartion has API Permission to Azure Storage and it run fine.
I then wanted to check my error-handling and output of the runbook when permissions are missing and removed the API Permission to Azure Storage on the App Registration. And nothing changed at all...The runbook succesfully created storage context and down-/uploaded the file without problem.
After some digging, I noticed that the object-id of the App Registration is different when I look at it in Access Control (IAM) of the storage container than when I load the object in Azure Active Directory (see pic below). So I thought well there must be some "noise" and removed and re-added the Role Assignement to the container. I then run into the error as expected.
After successfully worked on my error-handling i re-applied the permissions and...the error wont disapear. So I again looked at the objects and again...die object-ids where different. I had to remove the RBAC and re-add it to reflect the permission change. After re-adding still the same issue. I have different ID's.
Does anyone know why thats different? And why wont it reflect the permission change withour remove-re-add?
Thank you!
Storage Container vs AAD:
Azure AD app registration is backed by 2 directory objects: an application and a service principal. As its name implies, the latter is the principal for authentication/authorization. Thus, you will see 2 object ids.
Regarding the access issue, all the principal (user or service) needs is an RBAC role assigned, thus adding or removing application permissions won't make a difference.
Related
Need a help on how do I handle rotating keys on google cloud storage thats managed by one google account but being accessed by an app thats running on another google cloud account. I tried searching for solutions but couldn't find an answer
With IAM service you can grant permission at project level, and, for some resources, at resources level.
It's the case for your KMS keys where you can grant permission on the key rings
Or directly at the key level
Choose what works the best for your use case, and grant the service account of the external project with the correct permission (decrypter to read the files in the GCS, encryter to write files)
Note: A key rotation is a new version of a key.
I'm trying to apply the 'Application Administrator'role to a service principal to allow it to create other service principals in AD. I would have assumed that having the ability to manage all aspects of app registrations etc as explained in the docs here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/users-groups-roles/directory-assign-admin-roles.md would have allowed me to do this but i still cannot create new service principals in this way?
It looks as if it has created when looking in AD App Registrations but errors out with insufficient privileges
I have tried several approaches through bash & powershell, trying to create the AD application first then creating a service principal from that application id, also tried with the 'Global Admin' role and that works as expected however we're trying to limit as much as possible.
The command i'm trying to run in bash is
az ad sp create-for-rbac -n $spn_name --skip-assignment
And the equivalent in powershell
New-AzAdServicePrincipal -ApplicationId $appid
From an SPN with only the 'Application Administrator' role assigned.
Creating service principal failed for appid 'http://test-spn1'. Trace followed:
{Trace JSON}
Insufficient privileges to complete the operation.
To grant an application the ability to create, edit and delete all aspects of apps (both Application objects and ServicePrincipal objects, represented in the portal under App Registrations and Enterprise Apps, respectively), you should consider the following two app-only permissions (instead of the directory role):
Application.ReadWrite.All - Create Application and ServicePrincipal objects and manage any Application and ServicePrincipal objects.
Application.ReadWrite.OwnedBy - Create Application and ServicePrincipal objects (and automatically get set as owner), and manage Application and ServicePrincipal objects it is owner of (either because it created them, or because it was assigned as an owner).
These permissions are pretty close to what the Application Administrator directory role allows for users. They're available for both Azure AD Graph API (which is the API used by the Azure CLI, the Azure AD PowerShell module (AzureAD), and the Azure PowerShell module (Az)), and Microsoft Graph API (which you should not use for production scenarios, as the application and servicePrincipal entitles are still in beta). The permissions are documented here:
* https://learn.microsoft.com/graph/permissions-reference#application-resource-permissions
Warning: Both of these permissions are very high privilege. By being able to manage Application and ServicePrincipal objects, they can add credentials for those objects (keyCredentials and passwordCredentials) and in doing so, exercise any access which has been granted to those other apps. If an app granted Application.ReadWrite.All is compromised, pretty much all apps are compromised.
When using the CLI gcloud commands, I can do everything action on my database. Yet when I try to do the same thing from Go (from the same shell instance as I did when using the gcloud commands) I get an error with the message:
spanner: code = "PermissionDenied", desc = "Resource projects/todo/instances/todospanner/databases/tododb is missing IAM permission: spanner.sessions.create."
The code I am trying to run is taken from the example found here: https://cloud.google.com/spanner/docs/getting-started/go/
I can't find that permission (spanner.session.create) in the spanner permissions either. I've been playing around with setting all permissions I could find related to spanner, on the account which I've used to log in with gcloud.
my GOOGLE_APPLICATION_CREDENTIALS are set and I've also tried with gcloud beta auth.
Cloud Spanner IAM roles including the permission spanner.session.create are listed and described here: https://cloud.google.com/spanner/docs/iam#roles
Note how some of the roles are specific to a Person while others are Machine-specific (or Service Account specific).
You need to specify where are you connecting from or executing the code (Cloud Shell instance, VM running on GCE, on-prem machine or laptop) and to ensure that correct roles are assigned to a Person or a Service Account which is attempting to execute the code and access Cloud Spanner instance.
Consider this scenario:
your gcloud SDK may be well credentialed with person#domain.com account which has granted roles/spanner.admin role, so everything works fine for gcloud
the VM hosting your code and SDK is running as 12345678901-compute#developer.gserviceaccount.com Service Account and that one has no access to Cloud Spanner whatsoever, causing troubles.
More information on Service Accounts here:
https://cloud.google.com/compute/docs/access/service-accounts
Probably you didn't add access to your database tododb for account in the file pointed by GOOGLE_APPLICATION_CREDENTIALS. Use, for example, Cloud Spanner Database User role for this account in Google Console.
I need to create a temporary folder that will be accessed from the application only.
It means that even current user and system administrator are not able to open it from the Explorer.
While application is running, there'll be some files put into it. Once it's terminated, folder and all its content are deleted (again programmatically, no manual delete ability).
P.S. I found few posts here but there are no proper solution given yet.
Thanks in advance.
Windows security does not work that way. You cannot restrict access by application, only by user. If you want only your app to have access to a given resource then you have to create a new user account, configure the resource to grant access to only that user, and then run your app using that user, or at least have your app impersonate that user when needed. Files/folders are securable objects, and Windows security is based on user accounts.
I want to setup a Windows Azure development storage on my dev machine but I don't want to install SQL server on it because I want to use an existing one on another machine. Is it possible to set up the development storage service so that it uses the SQL server from another machine?
I tried calling dsinit with the /sqlinstance argument set to the remote machine, but it doesn't have any argument to allow me to specify the login credentials.
You can use undocumented command line argument /server:.
Example: dsinit /server:remote-sql-name
Added reservation for http://127.0.0.1:10000/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10001/ in user account DOMAIN\username.
Added reservation for http://127.0.0.1:10002/ in user account DOMAIN\username.
Creating database DevelopmentStorageDb20110816...
Granting database access to user DOMAIN\username...
The login already has an account under a different user name.
Changed database context to 'DevelopmentStorageDb20110816'.
Adding database role for user DOMAIN\username...
User or role 'user' does not exist in this database.
Changed database context to 'DevelopmentStorageDb20110816'.
Initialization successful. The storage emulator is now ready for use.
I think the short answer is no. Certainly dsinit is designed to only work on your local machine.
Can you setup the remote database server to use windows authentication and add the currently logged in user as an admin on that server? That may be enough to fool it (but I wouldn't hold my breath)
If this doesn't work and you still don't want to SQL on your development machine, then using the actual Azure storage is not a bad idea. It does cost some money, but not much and it does avoid some of the kinks that occur only in development storage.