Azure Key Vault .NET: starpniekservera iestatījumi noslēpumiem un marķiera pieprasījumiem

Piešķiriet vienu un to pašu Azure Core transportu SecretClientOptions un ClientSecretCredentialOptions pirms jebkura no diviem pieprasījuma ceļiem sākšanas.

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
    });

Izmantojiet lietotnes īstos vaultUrl, tenantId, clientId un clientSecret. Abi Transport = transport piešķīrumi ir apzināti: viens novirza marķiera iegūšanu, otrs – Key Vault noslēpumu pieprasījumus.

Saglabājiet vaultUrl kā faktisko glabātuves galapunktu. Apdarinātāja WebProxy satur starpnieku; publiski HTTP kandidāti ir pieejami HTTP starpniekserveru sarakstā, ja glabātuves tīkla politika atļauj šo maršrutu; konfigurējiet tā Credentials pirms klientu izveides, ja tīkls to pieprasa.

Atkārtoti izmantojiet transportu klientu darba slodzei un atbrīvojiet piederošos resursus izslēgšanas laikā. Veiksmīgs starpniekservera savienojums izveido maršrutu, taču Key Vault tīkla un piekļuves politikas joprojām nosaka, vai lietotne drīkst lasīt noslēpumu.

Saistītie raksti