Remove ClientID option on KeyVault AccessPolicy #1351
Labels
Comments
matthchr
added a commit
to matthchr/azure-service-operator
that referenced
this issue
Jan 11, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: Azure#1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed Azure#1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
matthchr
added a commit
to matthchr/azure-service-operator
that referenced
this issue
Jan 11, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: Azure#1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed Azure#1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
2 tasks
matthchr
added a commit
to matthchr/azure-service-operator
that referenced
this issue
Jan 11, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: Azure#1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed Azure#1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
matthchr
added a commit
to matthchr/azure-service-operator
that referenced
this issue
Jan 12, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: Azure#1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed Azure#1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
matthchr
added a commit
to matthchr/azure-service-operator
that referenced
this issue
Jan 12, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: Azure#1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed Azure#1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
matthchr
added a commit
that referenced
this issue
Jan 12, 2021
The operator was originally reconciling AccessPolicy's after the rest of the KV had been created (see: #1158). This isn't actually required because even doing this there are tons of reasons that this can fail. I've filed #1351 to track removing ClientID from the CRD in a future API version as there are a ton of obscure ways that we can fail to translate that ID into an ObjectID.
|
Leaving this open as an FYI, but not intending to fix this at this time as V1 is in critical fixes only mode. |
|
This issue has been automatically marked as stale because it has not had activity in 60 days. |
|
Closing this given ASOv1 is in maintenance mode and this isn't a critical issue |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the current behavior
We have
ClientIDtoday and we try to translate that into anObjectID.Describe the improvement
It would be great if this worked universally but unfortunately depending on what permissions the ASO service principal or managed identity has on the subscription it may or may not have permission to call the API required to look up the
ObjectIDfrom theClientID. The KeyVault API requires anObjectIDso rather than trying to be smart we should just make the customer supply the same ID that KeyVault expects.The text was updated successfully, but these errors were encountered: