-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
arm_role_assignment
: add principal_type
and skip_service_principal_aad_check
properties
#4168
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @jeffreyCline
Thanks for this PR - I've left some comments inline but this otherwise LGTM.
Thanks!
string(authorization.Group), | ||
string(authorization.MSI), | ||
string(authorization.ServicePrincipal), | ||
string(authorization.Unknown), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
presumably Unknown
shouldn't be in this list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it was on purpose Unknown
is actually a valid value,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just because it's in the list supported by the API doesn't mean it should be exposed to users unfortunately, Unknown is generally present to indicate a value that's unsupported on this API version (for example if it's been created on a newer/older version which is no longer supported)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tombuildsstuff I have asked the service team about the expected behavior and the purpose of the Unknown
value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR @jeffreyCline,
I've left some comments inline that i think should be addressed
@@ -164,6 +191,12 @@ func resourceArmRoleAssignmentRead(d *schema.ResourceData, meta interface{}) err | |||
d.Set("role_definition_id", props.RoleDefinitionID) | |||
d.Set("principal_id", props.PrincipalID) | |||
|
|||
principalType := d.Get("principal_type").(string) | |||
|
|||
if principalType != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we just mark the property as computed instead so its populated with whatever the default is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is my understanding that this needs to be defined by the user,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we shouldn't need this check at all? because right now we don't set it, the new property is optional with no default, so the user has to explicitly set it. And if in the case of the user not setting it there is nothing to read back then? If there is we can just mark it as computed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okie-dokie... fixed. :)
name = "%s" | ||
scope = "${data.azurerm_subscription.current.id}" | ||
role_definition_name = "Reader" | ||
principal_id = "${azuread_service_principal.test.id}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we fi the formatting here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kt I take that back... no we can't, if you do you get this error:
Error: authorization.RoleAssignmentsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidRoleAssignmentId" Message="The role assignment ID 'acctestRA21652c15-15eb-45b3-8a6c-b31feaa9e2df' is not valid. The role assignment ID must be a GUID."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
switching from tabs to spaces gives you that error??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, switching form %s
to testacc%s
gives me that error.
Could you also explain how exposing this property fixing AD replication eventually consistency? Those two things seem unrelated. |
Co-Authored-By: Tom Harvey <[email protected]>
Co-Authored-By: kt <[email protected]>
per conversation with the service team: "...there is one more parameter that I recommend you set on the role assignment create, including this parameter will eliminate a race condition where sometimes if you try to create an identity and then assign it immediately, the assignment fails because the identity hasn’t replicated in AAD yet. In a REST call to ARM you would include: “principalType”:”ServicePrincipal” … in the body of the PUT request to create the role assignment. I’m not sure what that translates to Terraform-wise." |
@jeffreyCline
Sounds like we want to default this to |
This attribute maps to the type of the Principal. If you are dealing with newly provisioned managed identities then setting to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @jeffreyCline
Thanks for pushing those changes - this now LGTM but I had one question around whether we could infer this field rather than making users specify it, WDYT?
Thanks!
@@ -64,6 +64,13 @@ func resourceArmRoleAssignment() *schema.Resource { | |||
Required: true, | |||
ForceNew: true, | |||
}, | |||
|
|||
"skip_service_principal_aad_check": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thinking about this, I'm fine with this approach, but is there any way that we could look this information up so that users don't need to specify it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given this is all a hack around broken AAD replication, and that there might be other reasons to set the type property (or at the least consume it) i'm more inclined to just expose the SDK/API type field and users can set it as desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per the service team:
-
The only valid values that are publicly exposed by our APIs are: User, Group, and ServicePrincipal.
-
This property is more relevant on the read path than write. For writes, the only relevant scenario is for ServicePrincipal. I see no value add in specifying
PrincipalType
as User or Group. The service anyways checks against AAD and fails the call if the principal is not found or the principal type in AAD doesn’t match what the request specified. Only forServicePrincipal
, if AAD returns principal not found, then role assignment create still proceeds in the new api-version. -
Don’t set this parameter unless explicitly dealing with newly created service principal.
-
As stated above this attribute makes more sense in the read scenario, the API will return User, Group, ServicePrincipal based on the type of the principal in AAD.
If we wanted to do that then I believe we would have to do a get on the service principal against AAD and see if it comes back with something or not, if the service principal returns not found we could then add this value to the call automatically and avoid having this value at all. Just depends on how you want to do it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from two minor comments LGTM now @jeffreyCline
## Attributes Reference | ||
|
||
The following attributes are exported: | ||
|
||
* `id` - The Role Assignment ID. | ||
|
||
* `principal_type` - The type of the `principal_id`, e.g. User, Group, Service Principal, Application, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can leave this as:
* `principal_type` - The type of the `principal_id`, e.g. User, Group, Service Principal, Application, etc. | |
* `principal_type` - The type of the `principal_id`. |
"sp": testAccAzureRMActiveDirectoryServicePrincipal_servicePrincipal, | ||
"group": testAccAzureRMActiveDirectoryServicePrincipal_group, | ||
"sp": testAccAzureRMActiveDirectoryServicePrincipal_servicePrincipal, | ||
"spType": testAccAzureRMActiveDirectoryServicePrincipal_servicePrincipalWithType, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this might be better as:
"spType": testAccAzureRMActiveDirectoryServicePrincipal_servicePrincipalWithType, | |
"spSkip": testAccAzureRMActiveDirectoryServicePrincipal_servicePrincipalWithAadSkip, |
arm_role_assignment
: add pricipal_type
and skip_servicepricipal_aad_check
properties
add `pricipal_type` and `skip_servicepricipal_aad_check` properties
arm_role_assignment
: add pricipal_type
and skip_servicepricipal_aad_check
propertiesarm_role_assignment
: add principall_type
and skip_service_principal_aad_check
properties
arm_role_assignment
: add principall_type
and skip_service_principal_aad_check
propertiesarm_role_assignment
: add principal_type
and skip_service_principal_aad_check
properties
This has been released in version 1.34.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.34.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! |
Including the
PrincipalType
parameter will eliminate a race condition where sometimes if you try to create an identity and then assign it immediately, the assignment fails because the identity hasn’t replicated in AAD yet.