i have an app (stateless) running as C# executable in my SF cluster. the App uses Managed identity to connect to Azure Key Vault. i have granted Key vault accss policy to the Virtual Machine Scale set managed identity, but when app tries to connect to Key vault, it gets exeption
" Azure.Identity.AuthenticationFailedException (-2146233088)
DefaultAzureCredential failed to retrieve a token from the included credentials.
EnvironmentCredential authentication unavailable. Environment variables are not fully configured?
Most of the articles talks about this exception when running on local machine. But i am running SF on azure, but still getting exception.
Any pointers on how to troubleshoot further.
Related
This is driving me crazy, been trying to get this to work for 3 days now: I'm trying to connect a kubernetes deployment to my Cloud SQL database in GCP.
Here's what I've done so far:
Set up the cloud SQL proxy to work as a sidecar in my deployment
Created a GKE service account and attached it to my deployment
Bound the GKE service account to my GCP service account
Edited to the service account (to what I can tell) is owner permission
Yet what I run the deployment in GKE I still get:
the default Compute Engine service account is not configured with sufficient permissions to access the Cloud SQL API from this VM. Please create a new VM with Cloud SQL access (scope) enabled under "Identity and API access". Alternatively, create a new "service account key" and specify it using the -credential_file parameter
How can I fix this? I can't find any documentation on how to set up the service account to have the correct permissions with Cloud SQL or how to debug this issue. Every single tutorial I can find ends with "bind your service account" and then stops. Nothing that describes what permissions are needed, and nothing about how to actually connect to the DB from my code (how would my code talk to the proxy?).
Please help
FINALLY got it to work!
Two major pieces that the main article on this (cloud.google.com/sql/docs/mysql/connect-kubernetes-engine) glosses over:
Properly setting up workload identity, for which I found these links to be very helpful:
a) https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity
b) https://www.youtube.com/watch?v=l-nws1e4B8M
To connect to the DB you have to have your code use the DB host 127.0.0.1
We have a release pipeline that is failing with following message:
resource ID for resource type 'Microsoft.Web/Sites' and resource name
'appservicename'. Error: Could not fetch access token for Managed
Service Principal. Please configure Managed Service Identity (MSI) for
virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400,
status message: Bad Request
We have 2 different service connections:
Azure Resource Manager using service principal authentication
Azure Resource Manager using managed identity authentication
The first one works like a charm. However, because the developer wanted to limit admin access on the Azure AD, he tried creating a managed identity authentication service connection which at first glance, since it allowed us to select the App Service, appeared to indicate it's working, until an actual deployment was triggered and it failed per the error message above.
After numerous searches online, I think this answer may be the clue to why this is failing with the managed identity authentication service connection yet succeeding with the service principal connection just fine.
I just want to confirm, is this truly the case? that a hosted agent doesn't support MSI based authentication, which is what we are using… or has that changed?
We are indeed using Microsoft agent pool.
It doesn't make sense for our app service to use a VM at this time. The use case just isn't applicable for the dashboards we have.
As it is written in the docs:
You are required to use a self-hosted agent on an Azure VM in order to use managed service identity
I assume that it was alway like that. Here we are talking abut MSI assigned to VM which serves as build agent. Not MSI which is identity of App Service. Why? Service Connection is an abstraction which makes easy authentication to your Azure Subscription. So it gives identity to VM and then when your perform some action against your Azure thanks to MSI Azure know that can perform that action. Another aption is authentication via Service Principal, but thi can be done from any VM (inlcuding MS Hosted) because it relies on Client Id and Client secret which is kept in service connections. And MSI have to be assigned to particular VM which cannot be done with MS Hosted agents.
I am just new to Azure Cloud and Devops, so forgive me if I may forget some critical info here.
So during creation of tasks for the release and selecting subscriptions, I get an error when trying to authorize the subscription (which I suspect is because of insufficient permissions associated to my account), so I go to advanced options to select the managed identity authentication.
After which no error shows now. So I set all remaining items and assign Deploy Azure App Service task. However during the running of the agent I get an error during Deploy Azure App Service step.
Error: Failed to get resource ID for resource type 'Microsoft.Web/Sites' and resource name 'sample-vue'. Error: Could not fetch access token for Managed Service Principal. Please configure Managed Service Identity (MSI) for virtual machine 'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad Request
I have already set my azure app service to have a system assigned managed identity, but still this error occurs. I can't find any answer, online, with regards to the error above so hoping that someone could help explain to me the problem and how to possibly fix it. My hunch now is that I may have some insufficient permissions, but I don't know what it may be.
Please try the following items:
Remove and re-add the service connection in DevOps.
Check the rights of the account on Azure subscription. Please verify if the account has at least contributor access on Azure subscriptions. Check https://learn.microsoft.com/en-us/azure/billing/billing-add-change-azure-subscription-administrator
I was recently ordered by our IT team to disable the NAT pools on my service fabric cluster due to security risks. The only way I could do this was to deploy a new cluster with all its components.
Because this is a test environment I opt to use a self signed cert without a password for my cluster, the certificate is in my vault and the cluster is up and running.
The issue I have now is when I try to deploy my application from an Azure Devops Release Pipeline I get the following message:
An error occurred attempting to import the certificate. Ensure that your service endpoint is configured properly with a correct certificate value and, if the certificate is password-protected, a valid password. Error message: Exception calling "Import" with "3" argument(s): "The specified network password is not correct.
I generated the self signed certificate in Key Vault, downloaded the certificate and used Powershell to get the Base64 string for the service connection.
Should I create the certificate myself, with a password?
With the direction of the two comments supplied, I ended up generating a certificate on my local machine using the powershell script included with service fabric's local run time.
A small caveat here is to change the key size in the script to a large key size than the default, because ke vault does not support 1024 keys.
I then exported the pfx from my user certificates added a password(this is required for the service connection) and impoted the new pfx into my key vault.
Redeployed my cluster and it worked.
I have a test console app that successfully retrieves a cert from the local computer Cert store and use this cert to get a token from AAD.
However, when I run this inside of a Windows service, AcquireTokenAsync() does not run and breaks the execution, although the cert is retrieved from the store.
I did notice a private key error : PrivateKey = '_certCred.Certificate.PrivateKey' threw an exception of type 'System.Security.Cryptography.CryptographicException'
Any advice would be helpful
It would be good if we have a source code and information about the accounts you are using so we can see where the certificate is stored, but based on your description:
It is possible that the user on which the service account is running does not have access to the certificate you are trying to access.
One possibility is to configure the service to run as System Account and then select the 'Allow the service to interact with Desktop'.