메인 콘텐츠로 건너뛰기

개요

CrewAI는 조직을 기존 역할 시스템(“레거시 RBAC”)에서 RBAC v2로 이전했습니다. 이 페이지에서는 이전 후 계정이 어떤 모습인지, 이전 용어가 새 용어에 어떻게 대응하는지, 조직이 RBAC v2로 전환된 후 무엇을 확인해야 하는지 설명합니다. 이전의 목표는 모든 사람의 접근 권한을 가능한 한 이전과 가깝게 유지하는 것이었습니다. 레거시 역할과 공유 설정은 팀과 부여로 바뀌었습니다. 아무도 다시 설정할 필요가 없었습니다.

이전 용어와 새 용어

이전 후 계정의 모습

Administrators 팀

조직 소유자였거나 레거시 Owner 역할을 가졌던 모든 사람은 CrewAI 관리 팀인 Administrators 팀에 속합니다. 이 팀은 조직의 모든 것에 대한 전체 접근 권한을 가집니다. 소유자라는 사실만으로는 더 이상 접근 권한을 얻지 못합니다. Administrators 팀에서 누군가를 제거하면 그 사람은 전체 접근 권한을 잃습니다.

레거시 역할마다 하나의 팀

각 레거시 역할(Owner 제외)은 커스텀 팀이 되었습니다:
  • 팀은 역할과 같은 이름을 가집니다. 예: Member, Developer, Support.
  • 팀은 역할과 같은 사람들로 구성됩니다. 역할이 없던 사람은 Member로 취급되었으므로 Member 팀에 속합니다.
  • 역할의 기능 권한은 팀이 보유한 역할이 되었습니다. 기능 권한을 참조하세요.
  • 역할과 공유되었던 모든 것은 팀과 공유되었습니다.
이 팀들은 일반 커스텀 팀입니다. 이름을 바꾸거나, 멤버와 역할을 변경하거나, 폐기할 수 있습니다.

공유

모든 공유가 이전되었습니다:
  • 사람과 공유된 리소스는 이제 해당 리소스에 대한 그 사람의 역할입니다.
  • 레거시 역할과 공유된 리소스는 이제 해당 리소스에 대한 그 역할의 팀의 역할입니다.
역할은 공유 수준에 따라 선택되었습니다. 공유 수준을 참조하세요.

사람들이 소유한 리소스

리소스를 소유했던 사람은 그 리소스에 대한 전체 제어 권한을 유지했습니다: 이제부터는 리소스를 생성한 사람이 자동으로 그 리소스의 Admin이 됩니다.

서비스 계정

서비스 계정에는 레거시 역할이 없었으므로 팀에 속하지 않았습니다. 대신 다음을 받았습니다:
  • 소유한 각 자동화에 대한 Automation Admin.
  • 소유한 각 애플리케이션 연결에 대한 Application Connection Admin.
  • API를 통해 Studio 프로젝트를 계속 삭제할 수 있도록, 조직 범위의 Studio Project Admin.

기능 권한

이 표는 각 레거시 기능 권한이 역할의 팀에 준 역할을 보여 줍니다. 별도 표시가 없으면 모두 조직 범위입니다.
조직에서 Git repositories RBAC 설정을 켜지 않았다면, 레거시 역할로 자동화를 생성할 수 있었던 팀 (crews_dashboards Manage 또는 studio_projects Manage)은 배포할 때 계속 저장소를 선택할 수 있도록 Git Repository Operator도 받았습니다.

기본 Member 팀이 보유한 것

기본 레거시 Member 역할은 Member 팀이 되었습니다. 이전 전에 Member 역할을 변경하지 않았다면, Member 팀은 다음을 보유합니다:
  • Studio Project Viewer, Studio Project Creator, Automation Creator
  • Agent Viewer
  • Skill Operator 및 Application Connection Creator
  • Agent Control Plane Viewer 및 ACP Policy Viewer
  • Git repositories RBAC 설정이 꺼져 있었다면 Git Repository Operator
  • Member 역할과 공유되었던 각 리소스에 대한 역할 (예: 조직 환경 변수)

공유 수준

각 공유는 해당 리소스에 대한 하나의 역할이 되었습니다. 공유에 둘 이상의 수준이 있었다면 가장 높은 수준이 사용되었습니다.

자동화

Crew Studio 프로젝트

기타 리소스

이 리소스들의 레거시 공유에는 수준이 없었습니다. 새 역할은 리소스를 공유받은 사람 또는 역할의 레거시 수준에 따라 달라집니다.

이제 달라진 점

대부분의 사람은 같은 접근 권한을 유지합니다. 다음은 가장 눈에 띌 가능성이 높은 차이점입니다.

접근 권한이 늘어나는 경우

  • Member 팀의 모든 사람이 조직의 모든 Studio 프로젝트를 열 수 있습니다. Member 역할에 Studio Manage가 있었기 때문입니다. 이전에는 멤버가 자신의 프로젝트와 자신과 공유된 프로젝트만 볼 수 있었습니다. 프로젝트를 여는 것은 읽기 전용이며, 실행하거나 편집하려면 여전히 해당 프로젝트에 대한 더 높은 역할이 필요합니다.
  • 자동화 공유가 단순해졌습니다. 보기 전용 자동화 역할이 없으므로, 자동화를 공유받은 사람은 누구나 이제 자동화를 실행하고, 트레이스를 보고, human-in-the-loop 요청에 응답할 수 있습니다.
  • 설정이 더 이상 소유자 전용이 아닙니다. 결제, 통합, 테마, 멤버 관리는 이전에 소유자가 필요했습니다. 이제는 Usage and Billing Admin, Organization Admin 또는 Identity and Access Admin을 가진 사람이면 누구나 열 수 있습니다.
  • 공유된 LLM 연결과 환경 변수가 표시됩니다. 공유받은 사람은 설정 페이지에서 해당 연결이나 변수를 볼 수 있습니다. Environment Variable Viewer는 변수의 값을 표시할 수 있습니다.

접근 권한이 줄어드는 경우

  • 일부 설정에 대한 읽기 전용 접근이 종료되었습니다. usage_dashboards, secret_providers, default_settings, workload_identity의 Read는 역할을 주지 않았습니다. 이를 복원하려면 기능 권한 표에서 해당하는 역할을 사람이나 팀에 부여하세요.
  • 자동화의 채팅 및 킥오프 화면을 사용하려면 해당 자동화에 대한 역할이 필요합니다. 이전에는 모든 멤버가 공유 없이도 자동화의 Crew UI에서 실행을 시작하거나, 상태를 확인하거나, 메모리를 사용할 수 있었습니다. 이제는 해당 자동화에 대해 최소 Automation Operator가 필요합니다.
  • Operator는 자동화 환경 변수 값을 보거나 실행을 삭제할 수 없습니다. 환경 변수 값을 보려면 Automation Editor 또는 Automation Admin이 필요합니다. 실행을 삭제하려면 Automation Admin이 필요합니다.
  • Editor는 자동화를 공유하거나 삭제할 수 없습니다. full_access 없이 manage_settings를 가졌던 사람은 이제 Automation Editor입니다. 공유와 삭제에는 Automation Admin이 필요합니다.
  • 공유된 애플리케이션 연결은 누군가 연결의 공유 버튼으로 공유하기 전까지 소유자와 Administrators 팀에게만 표시됩니다.
  • 서비스 계정과 사용자 API. 사용자를 초대하거나, 제거하거나, 역할을 변경하는 API 호출에는 Identity and Access Admin 역할이 필요합니다. 이러한 엔드포인트를 사용하는 모든 서비스 계정에 이 역할을 부여하세요.

접근 권한 관리 방식의 변화

  • 역할 페이지는 닫혔습니다. 레거시 역할은 더 이상 접근 권한을 제어하지 않으므로 변경해도 효과가 없습니다. 설정 → 팀과 설정 → 멤버를 사용하세요.
  • 초대에서 역할을 지정하지 않습니다. 새로 가입한 사람은 접근 권한이 없습니다. 초대를 수락한 후 팀에 추가하거나, SSO 그룹을 팀에 매핑해 자동으로 이루어지게 하세요.

이전 후 체크리스트

1

Administrators 팀 확인

설정 → 팀으로 이동해 Administrators를 엽니다. 전체 접근 권한을 가져야 하는 사람만 속해 있는지 확인하세요.
2

역할에서 만들어진 팀 검토

각 레거시 역할은 이제 같은 이름의 팀입니다. 멤버와 역할을 확인하세요. 더 명확한 이름이 도움이 된다면 팀 이름을 바꾸고, 더 이상 필요 없는 팀은 폐기하세요.
3

모든 Studio 프로젝트를 볼 수 있는 사람 결정

Member 팀은 모든 Studio 프로젝트를 열 수 있습니다. 범위가 너무 넓다면 Member 팀에서 Studio Project Viewer를 제거하고, 필요한 사람과 프로젝트를 공유하세요.
4

새로운 사람이 접근 권한을 얻는 방법 계획

새 멤버는 접근 권한 없이 시작합니다. 새로운 사람이 어떤 팀에 속할지 정하고, 초대를 수락한 후 추가하세요. SSO를 사용한다면 대신 그룹 매핑을 설정하세요.
5

서비스 계정 확인

설정 → 서비스 계정에서 API를 통해 사용자를 초대하거나 관리하는 모든 서비스 계정에 Identity and Access Admin을 부여하세요.
6

필요하면 읽기 전용 설정 접근 복원

누군가 사용량, 시크릿 제공자, 크루 스튜디오 기본값 또는 워크로드 아이덴티티에 대한 읽기 접근에 의존했다면, 해당하는 조직 역할을 부여하세요.

도움이 필요하신가요?

이전 후 예상과 다르게 보이는 부분이 있다면 지원팀에 문의하세요.