mirror of
https://github.com/crewAIInc/crewAI.git
synced 2026-07-01 21:28:10 +00:00
docs(secrets-manager): WI env vars now follow deployment assignment (#5881)
This commit is contained in:
Heitor Carvalho
@@ -56,15 +56,18 @@ icon: "book-open"
|
||||
|
||||
## الرؤية والنطاق
|
||||
|
||||
<Note>
|
||||
تتّبع متغيرات البيئة المدعومة بـ WI نفس نموذج الإسناد الذي تتّبعه متغيرات البيئة العادية: لا تحلّ الأتمتة سوى متغيرات البيئة المدعومة بـ WI المُسنَدة إليها صراحةً. أَسنِد متغير WI إلى أتمتة من صفحة متغيرات البيئة الخاصة بتلك الأتمتة؛ المتغيرات المُعرَّفة على مستوى المنظمة أو في مشروع Studio لا تُحلّ عند الإطلاق حتى تُسنِدها.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
تُشغَّل مرحلة جلب الأسرار في كل إطلاق، لكنها لا تقوم بعمل فعلي إلا حين تكون هناك متغيرات بيئة مدعومة بـ WI مُسنَدة إلى النشر. لكل متغير مُسنَد، يُحلّ وقت التشغيل القيمة من مزوّدك السحابي في كل إطلاق لـ crew أو flow أو training أو test أو checkpoint-restore ويكتبها في بيئة العملية. عند عدم وجود أي متغير مُسنَد، تكون المرحلة بلا أثر (no-op). وإلا فإن التكلفة تتناسب مع عدد المتغيرات المُسنَدة: تأخّر إضافي بسيط لكل إطلاق بالإضافة إلى إدخال واحد في سجل تدقيق السحابة لكل متغير.
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
تكوينات Workload Identity هي اليوم **عامة على مستوى المنظمة في كل نشر** — لا يوجد ربط لكل أتمتة. توجد نتيجتان جديرتان بالمعرفة قبل تبنّي مسار Workload Identity على نطاق واسع.
|
||||
على مستوى *تكوينات* Workload Identity، لا يزال النطاق اليوم عاماً على مستوى المنظمة. تُهيَّأ كل أتمتة في المنظمة استناداً إلى جميع تكوينات Workload Identity التي سجّلتها المنظمة، ولا يمكنك اليوم ربط تكوين Workload Identity محدد بأتمتة بعينها. تحديد نطاق Workload Identity لكل أتمتة موجود في خارطة الطريق. حتى ذلك الحين، سجِّل فقط تكوينات Workload Identity التي يحقّ لكل أتمتة في منظمتك استخدامها.
|
||||
</Warning>
|
||||
|
||||
- **يُشغّل كل إطلاق أتمتة مرحلة جلب الأسرار**، بصرف النظر عمّا إذا كانت الأتمتة تُشير إلى أي متغير بيئة مدعوم بـ WI. في كل إطلاق لـ crew أو flow أو training أو test أو checkpoint-restore، يقوم وقت التشغيل بجلب جميع متغيرات البيئة المدعومة بـ WI المُكوَّنة للنشر ويكتبها في بيئة العملية. التكلفة: تأخّر إضافي بسيط لكل إطلاق بالإضافة إلى إدخال واحد في سجل تدقيق السحابة لكل متغير بيئة مدعوم بـ WI.
|
||||
- **ترى جميع الأتمتات في النشر كل متغيرات البيئة المحلولة بواسطة WI.** لا يمكنك اليوم تقييد تكوين Workload Identity محدد (أو الأسرار التي يحلّها) لأتمتة بعينها. اعتبر الأسرار المدعومة بـ WI متاحة لكل أتمتة في المنظمة.
|
||||
|
||||
تحديد النطاق لكل أتمتة موجود في خارطة الطريق. حتى ذلك الحين، خطّط لاستخدام Workload Identity على مستوى المنظمة، وليس لكل سير عمل — واقصُر متغيرات البيئة المدعومة بـ WI على الأسرار التي يحقّ لكل أتمتة في المنظمة قراءتها.
|
||||
|
||||
## الأذونات
|
||||
|
||||
تتحكم ميزتان في CrewAI Platform بالوصول إلى مدير الأسرار:
|
||||
|
||||
@@ -56,15 +56,18 @@ Setting up Secrets Manager is a three-step flow that involves both your cloud pr
|
||||
|
||||
## Visibility & Scope
|
||||
|
||||
<Note>
|
||||
WI-backed environment variables follow the same assignment model as plaintext environment variables: an automation resolves only the WI-backed variables explicitly assigned to it. Assign a WI-backed variable to an automation from the Environment Variables page on that automation; variables defined at the organization level or in a Studio project are not resolved at kickoff until you assign them.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
The secret-fetch stage runs on every kickoff but only does work when WI-backed environment variables are assigned to the deployment. For each assigned variable, the runtime resolves the value from your cloud provider on every crew, flow, training, test, or checkpoint-restore kickoff and writes it into the process environment. With nothing assigned, the stage is a no-op. Otherwise, cost is proportional to the number of assigned variables: a small added latency per kickoff plus one cloud-side audit-log entry per variable.
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
Workload Identity configurations are **organization-wide on each deployment** today — there is no per-automation binding. Two consequences worth knowing before you adopt the Workload Identity path broadly.
|
||||
At the Workload Identity *configuration* level, scope is still organization-wide today. Every automation in the organization is bootstrapped against every Workload Identity configuration the org has registered, and you cannot today bind a specific Workload Identity configuration to a specific automation. Per-automation Workload Identity scoping is on the roadmap. Until then, only register Workload Identity configurations every automation in your organization is allowed to use.
|
||||
</Warning>
|
||||
|
||||
- **Every automation kickoff runs the secret-fetch phase**, regardless of whether the automation references any WI-backed environment variable. On every crew, flow, training, test, or checkpoint-restore kickoff, the runtime fetches all WI-backed environment variables configured for the deployment and writes them into the process environment. Cost: a small added latency per kickoff plus one cloud-side audit-log entry per WI-backed environment variable.
|
||||
- **All automations on the deployment see all WI-resolved environment variables.** You cannot today restrict a specific Workload Identity configuration (or the secrets it resolves) to a specific automation. Treat WI-backed secrets as available to every automation in the organization.
|
||||
|
||||
Per-automation scoping is on the roadmap. Until then, plan Workload Identity usage at the organization level, not per workflow — and keep WI-backed environment variables limited to secrets every automation in the organization is allowed to read.
|
||||
|
||||
## Permissions
|
||||
|
||||
Two CrewAI Platform features control access to Secrets Manager:
|
||||
|
||||
@@ -56,15 +56,18 @@ Secrets Manager 설정은 클라우드 공급자와 CrewAI Platform 양쪽 모
|
||||
|
||||
## 가시성 및 범위
|
||||
|
||||
<Note>
|
||||
WI 기반 환경 변수는 평문 환경 변수와 동일한 할당 모델을 따릅니다: 자동화는 명시적으로 할당된 WI 기반 변수만 해석합니다. 해당 자동화의 Environment Variables 페이지에서 WI 기반 변수를 자동화에 할당하세요; 조직 수준 또는 Studio 프로젝트에 정의된 변수는 할당하기 전까지 kickoff에서 해석되지 않습니다.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
시크릿 가져오기 단계는 매 kickoff마다 실행되지만, 배포에 WI 기반 환경 변수가 할당되어 있을 때만 실제로 작업을 수행합니다. 할당된 변수 각각에 대해, 런타임은 매 crew, flow, training, test, 또는 checkpoint-restore kickoff마다 클라우드 공급자에서 값을 해석하여 프로세스 환경에 기록합니다. 할당된 변수가 없으면 이 단계는 no-op입니다. 그렇지 않은 경우, 비용은 할당된 변수 수에 비례합니다: kickoff당 약간의 추가 지연 시간과 변수당 하나의 클라우드 측 audit log 항목.
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
Workload Identity 구성은 현재 각 배포에서 **조직 전체에 적용됩니다** — 자동화별 바인딩은 없습니다. Workload Identity 경로를 광범위하게 도입하기 전에 알아둘 만한 두 가지 결과가 있습니다.
|
||||
Workload Identity *구성* 수준에서는 오늘날에도 여전히 조직 전체에 적용됩니다. 조직 내 모든 자동화는 조직이 등록한 모든 Workload Identity 구성을 기반으로 부트스트랩되며, 오늘날에는 특정 Workload Identity 구성을 특정 자동화에 바인딩할 수 없습니다. 자동화별 Workload Identity 범위 지정은 로드맵에 있습니다. 그때까지는 조직 내 모든 자동화가 사용해도 되는 Workload Identity 구성만 등록하세요.
|
||||
</Warning>
|
||||
|
||||
- **모든 자동화 kickoff가 시크릿 가져오기 단계를 실행합니다.** 자동화가 WI 기반 환경 변수를 참조하는지 여부와 관계없이 실행됩니다. 매 crew, flow, training, test, 또는 checkpoint-restore kickoff마다, 런타임은 배포에 구성된 모든 WI 기반 환경 변수를 가져와 프로세스 환경에 기록합니다. 비용: kickoff당 약간의 추가 지연 시간과, WI 기반 환경 변수당 하나의 클라우드 측 audit log 항목.
|
||||
- **배포의 모든 자동화가 WI로 해석된 모든 환경 변수를 볼 수 있습니다.** 오늘날에는 특정 Workload Identity 구성(또는 그것이 해석하는 시크릿)을 특정 자동화로 제한할 수 없습니다. WI 기반 시크릿은 조직 내 모든 자동화에서 사용할 수 있다고 간주하세요.
|
||||
|
||||
자동화별 범위 지정은 로드맵에 있습니다. 그때까지는 Workload Identity 사용을 워크플로별이 아닌 조직 수준에서 계획하고 — WI 기반 환경 변수는 조직 내 모든 자동화가 읽을 수 있는 시크릿으로만 제한하세요.
|
||||
|
||||
## 권한
|
||||
|
||||
Secrets Manager 접근을 제어하는 두 가지 CrewAI Platform 기능:
|
||||
|
||||
@@ -56,15 +56,18 @@ Configurar o Secrets Manager é um fluxo de três passos que envolve tanto o seu
|
||||
|
||||
## Visibilidade & Escopo
|
||||
|
||||
<Note>
|
||||
Variáveis de ambiente atreladas a WI seguem o mesmo modelo de atribuição das variáveis de ambiente em texto puro: uma automação resolve apenas as variáveis atreladas a WI explicitamente atribuídas a ela. Atribua uma variável atrelada a WI a uma automação pela página de Variáveis de Ambiente dessa automação; variáveis definidas no nível da organização ou em um projeto Studio não são resolvidas em kickoff até que você as atribua.
|
||||
</Note>
|
||||
|
||||
<Note>
|
||||
A fase de busca de segredos é executada em todo kickoff, mas só realiza trabalho quando há variáveis de ambiente atreladas a WI atribuídas ao deployment. Para cada variável atribuída, o runtime resolve o valor a partir do seu provedor de nuvem em todo kickoff de crew, flow, training, test ou checkpoint-restore e o grava no ambiente do processo. Sem nada atribuído, a fase é um no-op. Caso contrário, o custo é proporcional ao número de variáveis atribuídas: uma pequena latência adicional por kickoff mais uma entrada no audit log do lado da nuvem por variável.
|
||||
</Note>
|
||||
|
||||
<Warning>
|
||||
As configurações de Workload Identity são hoje **abrangentes a toda a organização em cada deployment** — não existe vinculação por automação. Duas consequências que vale conhecer antes de adotar o caminho de Workload Identity de forma ampla.
|
||||
No nível das *configurações* de Workload Identity, o escopo ainda é abrangente a toda a organização hoje. Toda automação na organização é inicializada com base em todas as configurações de Workload Identity que a organização registrou, e hoje você não pode vincular uma configuração específica de Workload Identity a uma automação específica. Escopo por automação para Workload Identity está no roadmap. Até lá, registre apenas configurações de Workload Identity que toda automação da sua organização tenha permissão de usar.
|
||||
</Warning>
|
||||
|
||||
- **Todo kickoff de automação executa a fase de busca de segredos**, independentemente de a automação referenciar ou não alguma variável de ambiente atrelada a WI. Em todo kickoff de crew, flow, training, test ou checkpoint-restore, o runtime busca todas as variáveis de ambiente atreladas a WI configuradas para o deployment e as grava no ambiente do processo. Custo: uma pequena latência adicional por kickoff mais uma entrada no audit log do lado da nuvem por variável de ambiente atrelada a WI.
|
||||
- **Todas as automações no deployment enxergam todas as variáveis de ambiente resolvidas por WI.** Hoje você não pode restringir uma configuração específica de Workload Identity (ou os segredos que ela resolve) a uma automação específica. Trate os segredos atrelados a WI como disponíveis para toda automação da organização.
|
||||
|
||||
Escopo por automação está no roadmap. Até lá, planeje o uso de Workload Identity no nível da organização, não por workflow — e mantenha as variáveis de ambiente atreladas a WI limitadas a segredos que toda automação da organização tem permissão de ler.
|
||||
|
||||
## Permissões
|
||||
|
||||
Duas features da CrewAI Platform controlam o acesso ao Secrets Manager:
|
||||
|
||||
Reference in New Issue
Block a user