-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Get object_id of current user #3234
Comments
hey @joakimhellum-in Thanks for opening this issue :) I'd agree with this, I've actually been meaning to look into this for a while, however I believe it should take a slightly different direction to what's proposed above; so that the same Terraform Configuration can be used both with a Service Principal or a User Account, whereas today a slightly different configuration has to be used which is confusing. As such I believe it'd be better to deprecate the existing Thanks! |
@tombuildsstuff Yes, completely agree it would be better to introduce new field My only justification for splitting this into locals {
service_principal_object_id = "${data.azurerm_client_config.current.service_principal_object_id}"
user_object_id = "${data.azurerm_client_config.current.user_object_id}"
is_service_principal = "${local.service_principal_object_id != "" ? true : false}"
} But after your comment and second thought I guess it's better to possibly introduce new field similar to Run {
"environmentName": "AzureCloud",
"id": "ddab71c1-4649-46e2-8b63-9ecfb860c3fa",
"isDefault": true,
"name": "terraform-test-1",
"state": "Enabled",
"tenantId": "f4683495-fdad-496a-82fb-e2c3a24082f3",
"user": {
"name": "[email protected]",
"type": "user"
}
} Run {
"environmentName": "AzureCloud",
"id": "ddab71c1-4649-46e2-8b63-9ecfb860c3fa",
"isDefault": true,
"name": "terraform-test-1",
"state": "Enabled",
"tenantId": "f4683495-fdad-496a-82fb-e2c3a24082f3",
"user": {
"name": "http://terraform-test-1",
"type": "servicePrincipal"
}
} I don't have any use case for this other than doing a "who am I", meaning if object ID is user, then get user information from Azure AD. |
EDIT: Better version that also finds the user's Azure Active Directory Tenant ID WorkaroundHere's a workaround. Requires az cli to be present in the path.
|
If implementing a unified object ID for both user and service principal is too much, I'm thinking a simple if function would suffice for those who may need both.
My use case is sometimes
|
@JustinGrote fantastic workaround! Thanks a million! :-D 2 minor points:
|
@jpluscplusm I think I've since refactored it to be way simpler in 0.12, may post that later if I have time. |
Any update on this? Trying to create an access policy for a keyvault and need to get the authenticated users object id. |
I've run into the same use-case as #3234 (comment) |
This has been released in version 1.35.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example: provider "azurerm" {
version = "~> 1.35.0"
}
# ... other configuration ... |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
Community Note
Description
Terraform AzureRM provider currently supports getting the object ID of the logged in Service Principal, but not the object ID of the logged in user.
We can use the
azurerm_client_config
data source to get the current Service Principal object ID (service_principal_object_id
). It would be nice to be able to get the current user object ID as well.Use case: For currently logged in user to be able to self-assign permissions, for example when creating Key Vault. For reference Azure CLI does this when creating Key Vault using
az keyvault create
.New or Affected Resource(s)
Potential Terraform Configuration
References
The text was updated successfully, but these errors were encountered: