Skip to content
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

Can't connect to serverless SignalR instance when running locally without exposing secrets #290

Open
mgressman opened this issue Dec 6, 2022 · 0 comments

Comments

@mgressman
Copy link

All of the documentation points to putting the connection string for my serverless SignalR instance in my local.settings.json file for local development. I think we can all agree this approach is frequently frowned upon due to the possibility of committing secrets to the source code repo. Yes, I can remove the connection string before committing, but this is tedious and error prone. An approach I have taken in most cases is to move secrets to a secret.setting.json file and not commit that file to my repository.

My function app that contains the negotiate function has this in the Configure method of Startup.cs:

var configuration= new ConfigurationBuilder()
                .SetBasePath(builder.GetContext().ApplicationRootPath)
                .AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)
                .AddJsonFile("secret.settings.json", optional: true, reloadOnChange: true)
                .AddEnvironmentVariables()
                .Build();

For all other secrets (e.g., database connection, log analytics workspace authentication id, etc.), this works perfectly and as expected. Unfortunately, it does not work for the connection string for my SignalR service which leads me to believe the connection string location is hard-coded to local.settings.json and I can't change it. This is obviously very bad practice for keeping secrets out of my source control repo.

Ideally, I'd actually like to use Managed Identity instead of connection string, but have been unsuccessful getting that to work locally either. According the this documentation, I should do something like this:

{
  "Values": {
    "<CONNECTION_NAME_PREFIX>:serviceUri": "https://<SIGNALR_RESOURCE_NAME>.service.signalr.net"
  }
}

Following that guidance, my local.settings.json looks like this:

{
  "AppInsights": {
    "InstrumentationKey": "--SECRET--"
  },
  "LogAnalyticsWorkspace": {
    "AuthenticationId": "--SECRET--",
    "WorkspaceId": "--SECRET--"
  },
  "Host": {
    "CORS": "http://localhost:4200",
    "CORSCredentials": true
  },
  "IsEncrypted": false,
  "Values": {
    "AzureSignalRConnectionString:serviceUri": "https://<myserviceinstancename>.service.signalr.net",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet"
  }
}

That results in the following error:

[2022-12-06T23:47:23.167Z] Executed 'Negotiate' (Failed, Id=ef07e971-62b5-475d-80ed-aa014c0484db, Duration=11095ms)
[2022-12-06T23:47:23.169Z] System.Private.CoreLib: Exception while executing function: Negotiate. System.Private.CoreLib: One or more errors occurred. (One or more errors occurred. (The given AzureAD identity don't have the permission to generate access token.)). System.Private.CoreLib: One or more errors occurred. (The given AzureAD identity don't have the permission to generate access token.). Microsoft.Azure.SignalR.Common: The given AzureAD identity don't have the permission to generate access token.

Normally I would use DefaultAzureCredential to work with Managed Identity, but since this is a serverless function with a hub based on ServerlessHub, I am not sure how DefaultAzureCredential would even work for my negotiate function. I assume based on the documentation that all of that was handled for me internally. Here is my negotiate function:

[FunctionName(nameof(Negotiate))]
public SignalRConnectionInfo Negotiate(
    [HttpTrigger(AuthorizationLevel.Anonymous)] HttpRequest req)
{
    return Negotiate();
}

At the end of the day, I just want to get the connection string out of my local.settings.json file so it is not accidentally committed to source code repo while still being able to run locally for debugging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant