Azure Key Vault .NET: Mga Setting ng Proxy para sa mga Sikreto at Kahilingan ng Token

Itakda ang parehong Azure Core transport sa SecretClientOptions at ClientSecretCredentialOptions bago simulan ang alinman sa dalawang landas ng kahilingan.

var handler = new System.Net.Http.HttpClientHandler
{
    UseProxy = true,
    Proxy = new System.Net.WebProxy(
        "http://proxy.example.net:8080")
};

var transport = new Azure.Core.Pipeline.HttpClientTransport(handler);

var credential = new Azure.Identity.ClientSecretCredential(
    tenantId, clientId, clientSecret,
    new Azure.Identity.ClientSecretCredentialOptions
    {
        Transport = transport
    });

var vault = new Azure.Security.KeyVault.Secrets.SecretClient(
    new Uri(vaultUrl),
    credential,
    new Azure.Security.KeyVault.Secrets.SecretClientOptions
    {
        Transport = transport
    });

Gamitin ang tunay na vaultUrl, tenantId, clientId at clientSecret ng aplikasyon. Ang dalawang pagtatalaga ng Transport = transport ay sinadya: isa ang nagruruta ng pagkuha ng token at ang isa ang mga kahilingan ng sikreto ng Key Vault.

Panatilihin ang vaultUrl bilang tunay na endpoint ng vault. Ang WebProxy ng handler ay may hawak ng tagapamagitan; may mga pampublikong kandidatong HTTP sa listahan ng HTTP proxy kapag pinapayagan ng patakaran ng network ng vault ang rutang iyon; i-configure ang Credentials nito bago buuin ang mga kliyente kung kailangan ito ng network.

Gamitin muli ang transport para sa workload ng mga kliyente at pakawalan ang pagmamay-ari na mga mapagkukunan sa pagsara. Ang matagumpay na koneksyon sa proxy ay nagtatatag ng ruta, ngunit ang mga patakaran ng network at access ng Key Vault ang siyang nagpapasya kung maaaring basahin ng aplikasyon ang sikreto.

Kaugnay na mga artikulo