Azure Key Vault .NET: налады проксі для сакрэтаў і запытаў токенаў

Прызначце адзін і той жа транспарт Azure Core для SecretClientOptions і ClientSecretCredentialOptions, перш чым пачынаць любы з двух шляхоў запыту.

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

Выкарыстоўвайце рэальныя vaultUrl, tenantId, clientId і clientSecret праграмы. Дзве прызначэнні Transport = transport зроблены наўмысна: адно накіроўвае атрыманне токена, а другое — запыты да сакрэтаў Key Vault.

Пакіньце vaultUrl фактычнай канцавой кропкай сховішча. WebProxy апрацоўшчыка ўтрымлівае пасярэдніка; публічныя HTTP-кандыдаты даступныя ў спісе HTTP-проксі, калі сеткавая палітыка сховішча дазваляе гэты маршрут; наладзьце яго Credentials перад стварэннем кліентаў, калі гэтага патрабуе сетка.

Паўторна выкарыстоўвайце транспарт для працы кліентаў і вызваляйце належныя рэсурсы пры завяршэнні. Паспяховае злучэнне праз проксі стварае маршрут, але сеткавыя палітыкі і палітыкі доступу Key Vault па-ранейшаму вырашаюць, ці можа праграма чытаць сакрэт.

Падобныя артыкулы