RBAC і абмежаваныя API-ключы — AiHummer Дакументацыя

AiHummer абараняе сваю адміністрацыйную паверхню з дапамогай кіравання доступам на аснове роляў і абмежаваных API-ключоў. Ролі вызначаюць, кім чалавеку дазволена быць; абмежаваныя ключы дазваляюць перадаць частцы аўтаматызацыі толькі тыя прывілеі, якія ёй сапраўды патрэбны, замест ключа, які можа рабіць усё.

Ролі

Доступ да адміністрацыйнага API і адміністрацыйнага UI кіруецца ролямі. Роля вызначае, якія групы рэсурсаў прынцыпал можа праглядаць і якія можа змяняць.

Ролямі кіруюць на старонцы «Ролі» адміністрацыйнага UI. З каробкі ёсць убудаваныя ролі — owner (усё), admin, operator і member — яны даступныя толькі для чытання (пазначаны значком «Убудаваная», іх нельга змяніць або выдаліць). Акрамя іх можна ствараць уласныя ролі: у форме ролі задаюцца імя, апісанне і сетка правоў — чэкбоксы чытанне/запіс па кожным з ~19 даменаў рэсурсаў (агенты, размовы, інструменты, сакрэты, плагіны, налады, зацвярджэнні, API-ключы і г.д.; «запіс» аўтаматычна ўключае «чытанне»). У кожнай ролі паказана, колькі суб’ектаў яе выкарыстоўвае; роля, прызначаная камусьці, не можа быць выдалена, пакуль прызначэнні не зняты.

Спалучайце ролі з іншымі кантролямі на гэтым сайце — спіс дазволеных IP, карпаратыўны SSO і аўдыт-лог — так, каб кожнае адміністрацыйнае дзеянне было адначасова аўтарызавана і зафіксавана.

Абмежаваныя API-ключы адміністратара

API-ключы адміністратара нясуць скоупы, якія абмяжоўваюць тое, што ключ можа рабіць. Існуюць тры скоупы:

Скоуп	Дае
`admin:read`	Толькі-чытальны доступ да адміністрацыйных рэсурсаў (прагляд налад, размоў, аналітыкі і г.д.).
`admin:write`	Доступ на чытанне і запіс да адміністрацыйных рэсурсаў.
`admin:*`	Поўны адміністрацыйны доступ (эквівалентны ўсім адміністрацыйным скоупам).

Скоупы былі ўведзены міграцыяй 0073. Існуючыя ключы працягваюць працаваць; новыя ключы можна выпускаць з вузкім скоупам, так што, напрыклад, дашборд, які толькі чытае метрыкі, ніколі не трымае ключ, які мог бы змяніць налады.

[!TIP] Прымяняйце найменшыя прывілеі: інтэграцыя маніторынгу або справаздачнасці павінна атрымаць ключ admin:read, а не admin:write або admin:*. Прызначайце admin:* для ключоў, якім сапраўды трэба змяняць кожную групу рэсурсаў.

Выбар правільнага скоупа

Толькі-чытальныя інтэграцыі (дашборды, экспарцёры, праверкі статусу) → admin:read.
Аўтаматызацыя, якая стварае або рэдагуе рэсурсы (агенты прадастаўлення, імпарт ведаў, кіраванне раскладамі) → admin:write.
Аварыйны / поўны адміністрацыйны доступ → admin:*, які трымаецца як мага меншай колькасцю ключоў і рэгулярна ратуецца.

[!WARNING] Абмежаваны ключ усё яшчэ з’яўляецца ўліковымі данымі да адміністрацыйнага API. Захоўвайце яго ў сховішчы сакрэтаў або вашым уласным менеджары сакрэтаў, ніколі ў сістэме кантролю версій, і ратуйце яго, калі ён мог быць раскрыты.

Як кіруюцца ключы

API-ключы адміністратара кіруюцца праз адміністрацыйны API (/v1/admin/apikeys) і адміністрацыйны UI, дзе вы выпускаеце ключ, прызначаеце яго скоуп і адклікаеце яго, калі ён больш не патрэбны. Паколькі сам адміністрацыйны API абаронены OIDC і спісам дазволеных IP, выпуск ключа з’яўляецца аўтэнтыфікаванай, праверанай аўдытам аперацыяй.

Куды далей

Карпаратыўны SSO — аўтэнтыфікаваць людзей за ролямі праз SAML, LDAP, SCIM або OIDC.
Сетка, аўдыт і ізаляцыя ад сеткі — абмежаваць, адкуль можна дасягнуць адміністрацыйнага API, і весці аўдыт-след.
Сховішча сакрэтаў — дзе захоўваць ключы, якія вы выпускаеце.