.Net: Harden gRPC plugin address handling

[SergeyMenshykh]

Description

Add developer-controlled address configuration and validation for the gRPC plugin.

Motivation and Context

The gRPC plugin now supports GrpcFunctionExecutionParameters for configuring address handling, including an optional address override, allowed base addresses, and scheme restrictions.

Changes

• Introduced GrpcFunctionExecutionParameters class for developer-controlled gRPC channel configuration
• Added address validation with scheme and allowlist checks in GrpcOperationRunner
• Plumbed execution parameters through all public methods in GrpcKernelExtensions
• Updated and added unit tests

Type of change

• Bug fix (non-breaking change which fixes an issue)

[Copilot]

Pull request overview

This PR hardens the .NET gRPC plugin’s address handling by removing LLM-controlled address overrides and introducing developer-controlled execution parameters for channel configuration, including scheme restrictions and an address allowlist for SSRF mitigation.

Changes:

• Introduced GrpcFunctionExecutionParameters to allow developer-supplied HttpClient, optional address override, allowed base addresses, and allowed schemes.
• Updated GrpcOperationRunner to ignore address passed via KernelArguments and to validate the effective address (scheme + allowlist).
• Updated unit tests and removed the address parameter from gRPC operation parameter metadata.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
dotnet/src/Functions/Functions.UnitTests/Grpc/GrpcRunnerTests.cs	Updates/extends tests for the new address override + allowlist + scheme validation behavior.
dotnet/src/Functions/Functions.UnitTests/Grpc/Extensions/GrpcOperationExtensionsTests.cs	Verifies the gRPC operation no longer exposes an address parameter.
dotnet/src/Functions/Functions.Grpc/Model/GrpcOperation.cs	Removes the address argument constant and stops advertising address as an operation parameter.
dotnet/src/Functions/Functions.Grpc/GrpcOperationRunner.cs	Implements developer-controlled address override and adds scheme/allowlist validation.
dotnet/src/Functions/Functions.Grpc/Extensions/GrpcKernelExtensions.cs	Plumbs execution parameters through public extension methods and configures the runner accordingly.
dotnet/src/Functions/Functions.Grpc/Extensions/GrpcFunctionExecutionParameters.cs	Adds a new public execution-parameters type for developer-controlled configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Automated Code Review

Reviewers: 3 | Confidence: 90%

✓ Security Reliability

This PR is a well-designed security hardening that removes the LLM-controllable 'address' parameter from gRPC operations (preventing SSRF), adds scheme validation defaulting to HTTPS-only, and provides an optional allowlist for defense-in-depth. The validation logic in GetAddress correctly uses Uri.TryCreate for normalization before comparing, handles path-boundary attacks, and the constructor properly defaults to HTTPS when no schemes are specified. The removal of AddressArgumentName from both the model and parameter registration cleanly eliminates the attack surface. No blocking security or reliability issues found.

✓ Test Coverage

The PR adds comprehensive test coverage for the new gRPC address hardening features including allowlist validation, scheme rejection, path-boundary prefix checks, and address override validation. However, there is one notable coverage gap: no test verifies that configuring custom AllowedSchemes (e.g., permitting http for local development) actually succeds. All scheme-related tests only verify the rejection path (default https-only), leaving the positive custom-scheme path untested.

✗ Design Approach

The address-hardening logic looks sound overall, but the new execution-parameter plumbing introduces one design regression: a caller-suplied HttpClient is still wrapped in using during plugin creation, so the new API disposes the developer-owned client immediately after import and leaves the returned plugin holding a dead runner.

Flagged Issues

• GrpcKernelExtensions.cs:174 accepts executionParameters?.HttpClient but binds it to using var client, disposing the caller-owned HttpClient as soon as plugin creation returns. The plugin's GrpcOperationRunner retains this client for later invocation, so any subsequent function call will use a disposed instance. The repo's OpenAPI analogue explicitly avoids this pattern (see Functions.OpenApi/Extensions/OpenApiKernelExtensions.cs:122-124, 161-163, 204-206). Remove the using declaration for externally-provided clients.

---

Automated review by SergeyMenshykh's agents