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

Enhancing Configuration Flexibility for Azure Functions Triggers #2455

Open
Qualizorg opened this issue Mar 6, 2024 · 0 comments
Open

Enhancing Configuration Flexibility for Azure Functions Triggers #2455

Qualizorg opened this issue Mar 6, 2024 · 0 comments
Labels

Comments

@Qualizorg
Copy link

As developers, we appreciate the guidance provided through various tutorials, guides, and documentation regarding the integration of Azure Functions with various triggers like QueueTrigger, ServiceBusTrigger, and EventHub. The standard practice involves specifying connection configurations within the local.settings.json for local development and transitioning to Environment Variables within the Azure portal for production environments. This approach is depicted in the following snippets:

local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "ServiceBusConnection__fullyQualifiedNamespace": "namespace.servicebus.windows.net"
  },
  "Host": {
    "CORS": "*"
  }
}

Azure Service Bus Triggered Function

[Function("ServiceBusProcessDataAsync")]
public async Task ProcessDataAsync(
    [ServiceBusTrigger("sbq-data", Connection = "ServiceBusConnection")]
    ServiceBusReceivedMessage message,
    ServiceBusMessageActions messageActions)
{
    var data = JsonConvert.DeserializeObject<Data>(message.Body.ToString());
    _logger.LogInformation($"Processing data: {data.Id}");

    // Process data
    await Task.Delay(1000);

    // Complete the message
    await messageActions.CompleteMessageAsync(message);
}

We understand and agree with the rationale behind keeping connection strings, credentials, and sensitive data out of the codebase and source control to uphold security best practices. However, the current methodology, while effective in separating configuration from code, seems to lack flexibility, especially for scenarios involving identity-based connections that are inherently credential-less and managed through Role-Based Access Control (RBAC).

It would be beneficial to consider extending the configuration mechanism to also allow the use of appsettings.json for loading configurations related to such identity-based connections. This could streamline the development process, reduce manual configuration overhead, and potentially simplify the deployment and CI/CD pipelines without compromising security or best practices.

In summary, while we value the existing configuration methodologies for their security benefits, an enhanced approach that includes support for appsettings.json in identity-based connection scenarios could significantly improve developer experience and efficiency.

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

No branches or pull requests

1 participant