mirror of
https://github.com/KelvinTegelaar/CIPP.git
synced 2026-04-25 08:16:01 +03:00
[GH-ISSUE #344] Managed identity not assigned to the CIPP resource group. #164
Labels
No labels
API
Feature
NotABug
NotABug
Planned
Sponsor Priority
Sponsor Priority
bug
documentation
duplicate
enhancement
needs more info
no-activity
no-priority
not-assigned
pull-request
react-conversion
react-conversion
roadmap
security
stale
unconfirmed-by-user
unconfirmed-by-user
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/CIPP#164
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TUCU-Adam on GitHub (Dec 7, 2021).
Original GitHub issue: https://github.com/KelvinTegelaar/CIPP/issues/344
I've opted to scrap my prior install and set up again, just for kicks.
When building the app again from the auto deployment template, it fails to add the 'App Service or Function App' to the reader role for the resource group.
It does go through all other steps successfully and builds out the app. It also does create the proper ObjectID for the new managed identity for the app. It only fails to assign the identity to the Resource Group. I've added the managed ident to the RG manually so I don't know what repercussions the lack of the 'reader' role assignment for the managed identity for the resource group might have.
I am not sure if this is reproducible, due to me not having deleted my current install of CIPP while redeploying it. Perhaps there is a query for managed identities that expects to find only one to then assign to the resource group? Or perhaps it just needs a longer delay between steps to be able to query the new principle, so that it can add the role? No idea.
XXXXXX is just me redacting identifying info and not the actual output for the template.
{
"id": "/subscriptions/XXXXXX/resourceGroups/CIPP/providers/Microsoft.Resources/deployments/Microsoft.Template-20211207134001/operations/7FB76FCE5E937A50",
"operationId": "7FB76FCE5E937A50",
"properties": {
"provisioningOperation": "Create",
"provisioningState": "Succeeded",
"timestamp": "2021-12-07T18:41:19.9188388Z",
"duration": "PT21.2688518S",
"trackingId": "90d5b301-2575-4d44-88bf-9d5fa7239941",
"serviceRequestId": "da5bfcb1-6885-4acb-9efa-d94430e57543",
"statusCode": "OK",
"targetResource": {
"id": "/subscriptions/XXXXXX/resourceGroups/CIPP/providers/Microsoft.KeyVault/vaults/XXXXXX",
"resourceType": "Microsoft.KeyVault/vaults",
"resourceName": "XXXXXX"
}
}
},
{
"id": "/subscriptions/XXXXXX/resourceGroups/CIPP/providers/Microsoft.Resources/deployments/Microsoft.Template-20211207134001/operations/69BDCAD46D243569",
"operationId": "69BDCAD46D243569",
"properties": {
"provisioningOperation": "Create",
"provisioningState": "Failed",
"timestamp": "2021-12-07T18:41:00.4087948Z",
"duration": "PT1.7588078S",
"trackingId": "73ae98c1-9cb2-4392-aa99-2cda91474ad7",
"serviceRequestId": "b7e09d87-e042-4add-bba9-3b16322eba01",
"statusCode": "BadRequest",
"statusMessage": {
"status": "Failed",
"error": {
"code": "PrincipalNotFound",
"message": "Principal XXXXXX does not exist in the directory XXXXXX."
}
},
"targetResource": {
"id": "/subscriptions/XXXXXX/resourceGroups/CIPP/providers/Microsoft.Authorization/roleAssignments/XXXXXX",
"resourceType": "Microsoft.Authorization/roleAssignments",
"resourceName": "XXXXXX"
}
}
},
@KelvinTegelaar commented on GitHub (Dec 7, 2021):
You must delete the entire resource group and recreate it, this is a known azure issue in regards to sharing permissions via an arm
Template.
@TUCU-Adam commented on GitHub (Dec 7, 2021):
Hmm, just got the exact same error (different identity object IDs) on a brand new resource group after having deleted both the existing ones. RG name was one that I haven't used in the past.
Do I also need to re-fork the repo due to the prior failures?
@TUCU-Adam commented on GitHub (Dec 8, 2021):
Confirmed this morning that deleting and recreating the repo forks did the trick. Assume because of the workflow runs that make commits and reference the static web apps api token.
@TUCU-Adam commented on GitHub (Dec 8, 2021):
Also should clarify, from my initial post I wasn't installing into the same resource group when my first redeploy failed. It was into a new resource group within the same subscription.