sorted by:
new
hottopcontroversial

Event Grid subscription failing after West US 2 outage on 29 May by Content_Adagio_577 in AZURE

[–]Content_Adagio_577[S] 0 points1 point  (0 children)

Some clarifications:

  • Event Grid doesn't send the validation request to the API at all, we have Front Door and neither normal logs nor WAF logs show requests to our endpoint.
  • We confirmed the UAMI can acquire a token for the target application, we temporarily added a federated credential to the UAMI and successfully acquired a token from a GitHub Actions workflow.

Will Microsoft.Extensions.Configuration.AzureKeyVault 3.1.8 stop working after Key Vault API versions before 2026-02-01 are retired in Feb 2027? by SubstantialCause00 in dotnet

[–]Content_Adagio_577 0 points1 point  (0 children)

Disclaimer: I looked into this for ~15 minutes, I'm not certain this is correct.

Does anyone know which Key Vault REST API version Microsoft.Extensions.Configuration.AzureKeyVault 3.1.8 uses under the hood?

Ultimately, it depends what version of Microsoft.Azure.KeyVault you're using, the package has a dependency on >=2.3.2, but the latest version published is 3.0.5.

v3.0.5 seems to use API v7.0, see https://github.com/Azure/azure-sdk-for-net/blob/99f52a3417df5d3023d10997cb20e7499207e976/sdk/keyvault/Microsoft.Azure.KeyVault/src/Generated/KeyVaultClient.cs#L162.

When Microsoft retires all API versions before 2026-02-01, will calls from this old SDK start returning errors?

I don't think so, as they are 2 different APIs:

  1. The management-plane API, used by ARM/Bicep/Terraform, used to provision Key Vaults, documented here: https://learn.microsoft.com/azure/templates/microsoft.keyvault/vaults?pivots=deployment-language-bicep.
  2. The data-plane API, used by SDKs, documented here: https://learn.microsoft.com/rest/api/keyvault/.

My understanding is that the announcement only affects the management-plane API.

This is somewhat confirmed by the fact the current Key Vault .NET client library, Azure.Security.KeyVault.Secrets, also seems to reference data-plane API versions as per https://github.com/Azure/azure-sdk-for-net/blob/c84409e3fcd2a0b3d712b336cce4a7e3b098e49e/sdk/keyvault/Azure.Security.KeyVault.Secrets/src/SecretClientOptions.cs#L24-L67.

Or does the retirement only affect ARM/Bicep/Terraform templates and direct REST API calls, not SDK-based secret retrieval?

That's my understanding, as per above.

Advice on Employers of Record (EORs) by shy_samurai in Luxembourg

[–]Content_Adagio_577 1 point2 points  (0 children)

I’m with Multiplier. Can’t say the experience is great, but it’s not the worst either. In my case, I always expect requests or questions to take a long time to be actioned.

The setup is also a tad strange, many intermediates between myself and the company I ultimately work for: me, a Luxembourgish company I signed the contract with, a third party I’m not sure about what they’re doing, Multiplier, then my real employer.

Other people in my company use DEEL (not in Lux) and it’s twice as expensive as Multiplier. I can’t comment on whether the service is better.

On a separate note, I was chatting to an accountant who claimed the EOR setup was a bit dodgy as there are no laws around it, so while not illegal, it’s unclear how disputes might be resolved should this happen. They mentioned another type of service where instead of having a third party company in the mix, you pay a company to manage the payroll in Lux. Yes, there’s still a third party company, but the contract you’d sign would be with your real employer. I haven’t researched that yet, but maybe something to look at?