• /
  • EnglishEspañolFrançais日本語한국어Português
  • 로그인지금 시작하기

사용자의 편의를 위해 제공되는 기계 번역입니다.

영문본과 번역본이 일치하지 않는 경우 영문본이 우선합니다. 보다 자세한 내용은 이 페이지를 방문하시기 바랍니다.

문제 신고

플릿 컨트롤 액세스 관리

|View as Markdown (English)

이 가이드는 Fleet Control 작업을 위한 역할 기반 액세스 제어(RBAC) 설정 패턴을 제공합니다. 기본부터 엔터프라이즈까지 세 가지 구현 패턴을 다루며, UI 및 NerdGraph 예제를 모두 제공합니다.

어떤 접근 방식이 조직에 적합합니까?

  • 별도의 조직(권장): 여러 자율 비즈니스 단위를 관리하거나 단위 간 가시성이 전혀 없는 엄격한 계약자 격리가 필요한 경우, 멀티 테넌시(별도의 뉴렐릭 조직)를 사용하십시오. 이는 복잡한 사용자 지정 역할 없이 완벽한 경계 적용을 제공합니다. 여러 비즈니스 단위의 플릿 컨트롤 위임으로 이동하십시오.

  • 단일 조직 RBAC: 계약, 청구 또는 운영상의 제약으로 인해 단일 조직이 필요한 경우 이 가이드의 RBAC 패턴(기본, 고급 또는 엔터프라이즈)을 사용하십시오. 주의 사항: 사용자는 조직 전체에 다른 플릿이 존재한다는 것을 여전히 볼 수 있으며, 중앙 IT 부서는 각각의 새로운 플릿에 대해 액세스 권한 부여를 생성해야 합니다.

전제 조건

아래 패턴을 설정하기 전에:

  • 전체 플랫폼 사용자: 모든 Fleet Control 권한에는 전체 플랫폼 사용자 유형이 필요합니다.
  • Pro 또는 엔터프라이즈 에디션: 이 패턴에서 사용하는 커스텀 역할 및 커스텀 그룹을 만드는 데 필요합니다.
  • 인증 도메인 관리자 역할: Authentication domain manager 역할이 있는 사용자는 특정 플릿에 그룹과 역할을 할당하는 액세스 권한 부여를 만들 수 있습니다. 이는 모든 액세스 권한 부여 작업에 대한 뉴렐릭 플랫폼 요구 사항입니다.
  • 초기 Agent Control 설정: 시스템 ID를 생성하기 위해 일회성으로 Authentication domain manager 역할이 필요합니다.
  • 플릿 및 설정 만들기: Organization product admin 역할이 필요하며, 이 역할은 기본 User 그룹의 모든 사용자에게 자동으로 부여됩니다.
  • 배포 실행: Organization Manager 역할이 필요하며, 이는 기본 Admin 그룹의 모든 사용자에게 자동으로 부여됩니다. 또는 Fleet manager 역할이나 Deploy 권한을 가진 사용자 지정 역할은 조직 전체에 영향을 미치지 않고 특정 플릿에 이를 부여합니다.

역할 요구 사항에 대한 일반적인 오해

많은 팀이 모든 Fleet Control 작업에 Authentication domain manager이(가) 필요하다고 가정합니다. 이는 사실이 아닙니다.

Authentication domain manager 다음에만 필요합니다:

  1. 초기 Agent Control 설정, 시스템 ID를 생성하는 일회성 작업입니다.

  2. 액세스 권한 부여 생성, 이는 그룹을 플릿에 할당합니다.

    플릿 생성 및 설정 생성을 의미하는 지속적인 플릿 관리에는 대부분의 사용자가 이미 가지고 있는 Organization product admin만 필요합니다.

플릿 컨트롤 권한 구성 방법

커스텀 역할을 만들 때 Fleet Control 권한은 테이블로 표시됩니다: 리소스에 대한 행과 Read, Modify, Delete 및 Other에 대한 열. 각 체크박스는 개별 권한이 아닌 일련의 관련 작업을 부여합니다. 표시되는 행은 역할의 범위에 따라 다릅니다.

조직 범위 역할은 조직 내 모든 플릿을 포함하는 Fleets (all) 행을 갖습니다:

허가다루는 내용
Read플릿, 관리되는 엔티티의 에이전트, 설정 및 해당 콘텐츠, 플릿 멤버십, 승인 정책 보기
Modify플릿 생성 및 업데이트, 설정 작성 및 버전 추가, 그리고 읽기(Read)의 모든 항목
Delete플릿, 설정 및 배포 삭제
Other: Deploy배포를 생성, 편집, 실행 및 삭제하고 플릿에 있는 관리형 엔티티를 변경합니다
Other: Approve configurations설정 버전을 승인하거나, 변경을 요청하거나, 거부합니다.
Other: Configure organization governance승인 정책을 설정하고 변경하십시오.

플릿을 대상으로 하는 엔티티 범위 역할은 Fleets (individual) 행을 얻으며, 역할이 부여된 플릿만 다룹니다:

허가다루는 내용
Modify플릿의 이름을 바꾸고, 설명을 편집하며, 멤버십을 봅니다
Delete플릿을 삭제합니다.
Other: Deploy플릿에 대한 배포를 생성, 편집, 실행 및 삭제하고, 여기에 포함된 관리형 엔티티를 변경하십시오.

플릿 범위 역할은 읽기 액세스를 대체하는 것이 아니라 이를 기반으로 구축됩니다.

Fleets (individual) 행에는 Read 권한이 없습니다. 플릿 범위 역할은 애초에 Fleet Control을(를) 볼 수 있는 권한이 아니라 플릿에 대해 작업할 수 있는 권한을 부여합니다.

사용자는 조직 범위 역할의 읽기 액세스 권한도 필요하며, 이는 일반적으로 기본 User 그룹을 통해 부여됩니다. 다른 권한이 없는 멤버로 구성된 그룹에 플릿 범위 역할을 부여하면, 해당 멤버는 작업할 대상을 볼 수 없습니다.

설정 승인 및 승인 정책 설정은 조직 범위의 역할에만 사용할 수 있으므로, 승인 권한을 특정 플릿으로 범위를 지정할 수 없습니다. 자세한 내용은 설정 승인을 참조하고, 권한 부여 방법은 승인 권한 위임을 참조하십시오.

기본 패턴: 단일 플릿 권한(FGA)

Fleet Control 엔티티 범위의 액세스 권한 부여를 통해 세분화된 액세스(FGA)를 지원합니다. 기본 제공되는 Fleet manager 역할은 특정 플릿 엔티티로 범위를 지정할 수 있으며, 이를 통해 그룹은 Organization Manager 없이도 배포를 포함한 해당 플릿에 대한 전체 운영 제어 권한을 갖게 됩니다.

이를 통해 팀에 조직의 모든 플릿에 대한 액세스 권한을 부여하지 않고도 특정 플릿을 관리할 수 있는 액세스 권한을 부여할 수 있습니다.

UI 워크스루

  1. 플릿을 생성하십시오(아직 생성되지 않은 경우):

    1. 이동 All capabilities > New Relic Control > Fleets
    2. 딸깍 하는 소리 Create a fleet
    3. 예를 들어 다음과 같이 이름을 지정하십시오. production-us-east-fleets
    4. 플릿 GUID를 저장하고 기록합니다.
  2. 타겟 그룹 생성 또는 식별:

    1. 이동 Administration > Access management > Groups
    2. 새 그룹(예: prod-us-east-fleet-operators)을 생성하거나 기존 그룹을 사용하십시오.
    3. Create a group 모달에서 Add users 드롭다운 메뉴를 통해 지금 사용자를 추가하거나, 나중에 그룹을 편집하여 추가하십시오.
    4. 그룹 ID를 확인하십시오.
  3. 엔티티 범위 액세스 권한 부여:

    1. 이동 New Relic Control > Fleets
    2. 플릿의 행에서 케밥 메뉴를 열고 다음을 선택합니다 Fleet permissions
    3. Fleet permissions 모달에서 그룹을 선택하고 Fleet manager을(를) 역할로 선택하십시오. 필요에 따라 그룹 및 역할 쌍을 추가하십시오.
    4. Save을(를) 클릭하면 쌍당 하나의 액세스 권한 부여가 생성됩니다.

플릿 권한이 누락되었거나 잠긴 상태로 열리는 경우

Fleet permissions 메뉴 항목에는 Authentication domain manager 역할이 필요합니다. 이 역할이 없으면 플릿의 행에 작업이 표시되지 않거나 모달이 부분적으로 사용 가능한 상태가 아닌 잠긴 상태로 열립니다.

권한 부여는 Create fleet 대화 상자를 통해 플릿 생성 시 연결될 수도 있습니다.

결과: 이제 prod-us-east-fleet-operators의 멤버는 production-us-east-fleets에 대해서만 배포를 실행하고 멤버를 관리할 수 있습니다. 다른 플릿은 수정할 수 없습니다. 읽기 액세스는 이 권한 부여가 아니라 조직 범위 역할에서 비롯되므로 다른 플릿이 존재한다는 것은 계속 볼 수 있습니다.

NerdGraph 자동화

mutation GrantFleetAccess {
authorizationManagementGrantAccess(
grantAccessOptions: {
grantee: { type: GROUP, id: "YOUR_GROUP_ID" }
entityAccessGrants: {
entity: { id: "YOUR_FLEET_GUID", type: "fleet" }
roleId: "YOUR_ROLE_ID"
}
}
) {
accessGrants {
id
}
}
}

ID를 찾는 방법:

  • 플릿 GUID: 플릿 세부 정보 페이지 URL에서 확인하거나 NerdGraph Fleet Control 튜토리얼을 통해 플릿을 쿼리하십시오.
  • 그룹 ID: Administration > Access management > Groups, 그룹을 클릭하십시오. ID는 URL에 있습니다.
  • 역할 ID: 알려진 문제의 해결 방법을 사용하여 쿼리하십시오.

고급 패턴: 수명 주기 분리를 위한 사용자 지정 역할

서로 다른 Fleet Control 권한을 가진 두 개의 사용자 지정 엔티티 범위 역할을 생성한 다음, 동일한 플릿 엔티티의 다른 그룹에 각각 부여하십시오. Fleet manager 에는 수정, 삭제 및 배포가 함께 포함되어 있으므로, 그룹이 가져야 할 권한보다 더 많은 권한이 부여되는 경우 이를 분리하십시오.

이를 통해 두 그룹이 동일한 플릿에서 작업하는 동안 플릿의 정의 및 멤버십을 변경할 수 있는 사용자와 배포를 실행할 수 있는 사용자를 분리할 수 있습니다.

예제 블루프린트: 사용자 지정 역할 설계

이 섹션에서는 아키텍처 권한을 배포 실행과 분리하기 위해 권한이 낮은 커스텀 역할을 설계하는 방법에 대한 권장 예를 제공합니다.

두 역할 모두 엔티티 범위이며 Fleet을(를) 타겟으로 합니다:

역할허가보유자가 할 수 있는 작업할당 대상
Fleet authorModify플릿 이름을 변경하고, 설명을 편집하고, 멤버십을 확인하십시오.플랫폼 운영 팀
Fleet deployerOther: Deploy배포를 생성, 편집, 실행 및 삭제하고, 플릿에 있는 관리되는 엔티티를 변경합니다.앱 팀 및 계약자

Delete은(는) 선택하지 않은 상태로 두는 별도의 권한이므로 두 역할 모두 플릿을 삭제할 수 없습니다.

설정 작성은 두 역할 중 어느 것에도 포함되지 않습니다. Fleet Control의 설정은 플릿에 속하기보다는 조직 수준의 객체이기 때문입니다. 설정 작성은 Organization product admin에 포함되어 있으며, 기본 User 그룹은 이미 이를 가지고 있습니다. 실제로는 작성자가 설정을 작성하고, 이러한 플릿 범위의 역할이 무엇을 어디에 배포할지 제어합니다.

UI 워크스루

  1. 커스텀 역할을 만듭니다. 각각에 대해:

    1. 이동 Administration > Access management > Roles
    2. 딸깍 하는 소리 Add a role
    3. 역할 범위의 경우 Single item or entity을(를) 선택한 다음 클릭하십시오. Next
    4. Select what you want to configure access to에서 선택하십시오. Fleet
    5. 역할에 이름을 지정합니다. 예: Fleet author
    6. Set permissions 아래에서 Fleet Control을(를) 확장하고 Fleets (individual) 행에서 역할이 수행할 작업을 선택합니다: 작성자 역할의 경우 Modify, 배포자 역할의 경우 Other 아래의 Deploy.
    7. 저장한 다음 두 번째 역할에 대해 반복하십시오.
  2. 각 역할에 대한 그룹 만들기:

    1. 작성자를 위한 fleet-architects 그룹을 생성하고, Create a group 모달의 Add users 드롭다운 메뉴를 통해 관련 사용자를 추가하거나 나중에 그룹을 편집하여 추가하십시오
    2. 동일한 방법으로 배포자를 위한 fleet-deployment-operators 그룹을 생성하십시오
  3. 각 그룹에 엔티티 범위 액세스 권한 부여:

    1. New Relic Control > Fleets(으)로 이동하여 타겟 플릿에서 케밥 메뉴를 열고 선택하십시오. Fleet permissions
    2. 그룹 및 역할 쌍을 추가하십시오: fleet-architects 및 Fleet author
    3. 그룹 및 역할 쌍을 추가하십시오: fleet-deployment-operators 및 Fleet deployer
    4. 저장하면 두 권한 부여가 함께 생성됩니다.

커스텀 역할은 자체적으로 새로운 권한을 얻지 않습니다

사용자 지정 역할에는 관리자가 추가한 내용만 포함됩니다. 표준 역할은 새로운 조직 범위의 기능이 출시될 때 해당 권한을 받으므로, 나중에 Fleet Control에서 기능을 추가하는 경우 누군가가 해당 기능을 가져야 하는 각 사용자 지정 역할에 이를 추가해야 합니다.

새로운 Fleet Control 기능을 자동으로 받아야 하는 사용자의 경우 대신 표준 역할을 할당하십시오.

NerdGraph 자동화

사용자 지정 역할은 UI에서 생성됩니다. 역할 생성에는 확인란에 표시된 권한 이름 대신 내부 권한 식별자가 사용되므로, 역할 자체를 구축하기 위한 실용적인 API 경로는 없습니다.

역할이 존재하면 각 역할의 ID를 전달하여 기본 패턴과 동일한 뮤테이션으로 역할을 부여하십시오.

결과: 플릿 작성자는 자신이 소유한 플릿을 구성할 수 있지만 배포를 실행할 수는 없습니다. 배포 운영자는 배포를 실행할 수 있지만 플릿을 재정의하거나 삭제할 수는 없습니다.

엔터프라이즈 패턴: 위임된 그룹 관리

그룹 멤버십 관리를 위임하려면 그룹 범위 권한 부여와 함께 Group admin 역할을 사용하십시오.

이를 통해 팀 리더는 전체 Authentication domain manager 권한이 없어도 팀의 그룹에서 멤버를 추가하고 제거할 수 있습니다.

UI 워크스루

  1. 관리자 그룹 만들기:

    1. 이동 Administration > Access management > Groups
    2. 그룹 생성 fleet-team-leads
    3. 팀 리더를 멤버로 추가하십시오.
  2. 타겟 그룹에 Group admin [그룹 관리자] 역할 부여:

    1. 이동 Administration > Access management > Access grants
    2. 딸깍 하는 소리 Create new grant
    3. 다른 그룹을 타겟으로 하는 부여 유형인 그룹 부여를 선택하십시오.
    4. 그룹 선택 fleet-team-leads
    5. 역할: Group admin
    6. 팀 리더가 관리할 수 있어야 하는 그룹을 선택하십시오. 예를 들어 fleet-architects 및 fleet-deployment-operators
    7. 구하다

결과: 이제 fleet-team-leads의 구성원은 Authentication domain manager 역할 없이도 fleet-architects 및 fleet-deployment-operators에서 사용자를 추가하고 제거할 수 있습니다.

중요한 제한 사항

Group admin 그룹에 누가 있는지 관리할 수 있지만, 새로운 액세스 권한을 생성하거나 새로운 플릿에 그룹을 할당할 수는 없습니다. 새로운 플릿이 생성되면, Authentication domain manager 권한이 있는 누군가가 해당 플릿에 대한 액세스 권한을 생성해야 합니다.

NerdGraph 자동화

mutation DelegateGroupManagement {
authorizationManagementGrantAccess(
grantAccessOptions: {
grantee: { type: GROUP, id: "YOUR_TEAM_LEADS_GROUP_ID" }
groupAccessGrants: [
{ groupId: "YOUR_TARGET_GROUP_ID", roleId: "YOUR_GROUP_ADMIN_ROLE_ID" }
]
}
) {
accessGrants {
id
}
}
}

다수의 비즈니스 단위에 플릿 컨트롤 위임

이 섹션에서는 다수의 자율적인 비즈니스 단위를 보유하고 있으며 Fleet Control 관리를 위임해야 하는 고객에게서 확인한 시나리오를 간략하게 설명합니다. 위의 패턴을 사용하여 권장 솔루션과 대안적인 접근 방식을 모두 제공합니다.

시나리오

예: ByteFlix Entertainment는 단일 뉴렐릭 조직 하에서 운영되는 여러 자율적인 사업부를 갖춘 대규모 미디어 회사입니다.

  • 스트리밍 서비스인 ByteFlix+
  • BBS, 방송 네트워크인 ByteFlix Broadcast System
  • PixelTV, 케이블 네트워크

조직 구조

중앙 IT:

  • 두세 명의 사람만 Organization Manager 및 Authentication domain manager 역할을 가지고 있습니다.
  • 이들은 뉴렐릭 라이선싱 및 거버넌스를 관리합니다.
  • 이들은 모니터링 엔티티를 설정하거나 생성하지 않습니다.
  • 이들은 액세스 관리 변경의 병목지점입니다.

비즈니스 단위:

  • 각 단위는 동일한 뉴렐릭 조직 아래에 별도의 계정을 가지고 있습니다.
  • 각 단위는 자체 옵저버빌리티를 독립적으로 관리합니다.
  • 많은 부서에서 계약업체를 사용하여 뉴렐릭 Infrastructure를 관리합니다.

과제

ByteFlix는 Fleet Control을(를) 도입하려고 하지만 다음과 같은 문제에 직면합니다:

  1. 엄격한 비즈니스 단위 격리 필요: ByteFlix+ 팀은 BBS 또는 PixelTV 인프라를 관리해서는 안 됩니다.
  2. 계약자 위임: 부서 리더는 중앙 IT 부서를 거치지 않고 계약자를 온보딩해야 합니다.
  3. 수명 주기 분리: 플랫폼 운영팀은 플릿을 구성하고 앱 팀은 배포해야 하지만, 앱 팀이 플릿을 삭제하거나 재정의할 수는 없어야 합니다.
  4. 광범위한 관리자 권한 부여 없음: 중앙 IT 부서는 보안 문제로 인해 단위 팀에 Authentication domain manager을(를) 부여하지 않습니다.

권장 솔루션: 별도의 조직

ByteFlix의 조직 구조를 고려할 때, 멀티 테넌시가 이상적인 솔루션입니다.

의미하는 바

ByteFlix는 여러 계정이 있는 하나의 조직 대신 세 개의 독립적인 뉴렐릭 조직을 생성합니다:

  • 자체 계정을 가진 ByteFlix+ 조직
  • 자체 계정을 보유한 BBS 조직
  • PixelTV 조직, 자체 계정 포함

각 비즈니스 단위는 자체적으로 격리된 뉴렐릭 조직이 됩니다.

혜택

  1. 완전한 비즈니스 단위 격리: Fleet Control을(를) 포함한 조직 범위의 기능은 해당 단위의 조직 내 데이터만 볼 수 있습니다.
  2. 교차 단위 가시성 없음: ByteFlix+ 사용자는 BBS 또는 PixelTV 엔티티를 볼 수 없으며, 이는 조직 경계에 의해 보장됩니다.
  3. 자율 관리: 각 부서는 다른 부서에 영향을 주지 않고 자체 인증 도메인 관리자와 조직 관리자를 보유합니다.
  4. 계약자 위임: 각 단위는 중앙 IT 또는 다른 단위를 개입시키지 않고 계약자 액세스 권한을 부여할 수 있습니다
  5. 더 단순한 권한: 격리를 적용하기 위해 엔티티 범위의 권한 부여나 사용자 지정 역할이 필요하지 않습니다

공유 서비스는 어떻습니까?

뉴렐릭 계정 공유를 사용하면 계정이 조직 경계를 넘나들 수 있습니다. ByteFlix에 단위 간 가시성이 필요한 중앙 집중식 로깅 또는 공유 인프라와 같은 공유 플랫폼 서비스가 있는 경우, 해당 계정을 여러 조직에 공유할 수 있습니다.

예를 들어, 중앙 IT는 공유 플랫폼 계정이 있는 공유 옵저버빌리티 조직을 유지 관리하고, ByteFlix+, BBS 및 PixelTV 조직은 각각 계정 공유를 통해 해당 계정에 대한 읽기 액세스 권한을 갖습니다.

트레이드오프

장점:

  • 조직 경계에 의해 시행되는 가장 강력한 격리 모델
  • 엔티티 범위의 권한 부여가 필요 없는 가장 단순한 권한 모델
  • 각 부서는 완전히 자율적으로 운영됩니다.

단점:

  • 단순한 권한 변경이 아닌 조직 개편이 필요합니다.
  • 조직별로 청구 및 라이선스가 분리되어 계약 구조에 영향을 미칠 수 있습니다.
  • 공유 서비스에는 계정 공유 설정이 필요합니다.
  • 일부 교차 조직 보고에는 커스텀 대시보드 또는 Data Plus 기능이 필요합니다.

독립적인 조직을 위한 다음 단계

이 모델을 추진하려면 멀티 테넌시를 참조한 다음, 계정 담당자에게 문의하여 공유 서비스 워크플로우, 유닛을 별도의 조직으로 이동하기 위한 마이그레이션 계획, 공유 플랫폼 서비스에 대한 계정 공유, 계약 및 청구 관련 영향에 대해 논의하십시오.

대안 솔루션: 단일 조직 내의 RBAC 패턴

계약 제약, 일정 또는 조직의 저항으로 인해 ByteFlix가 별도의 조직으로 이동할 수 없는 경우, 단일 조직 내에서 이 가이드의 RBAC 패턴을 사용하여 유사한 결과를 얻을 수 있습니다.

패턴 1: 엔티티 범위 액세스(FGA)

해결 방법: 단일 조직 내의 비즈니스 단위 분리.

작동 방식: 세분화된 액세스를 사용하여 각 단위의 그룹에 특정 플릿 엔티티에 대한 액세스 권한만 부여합니다.

예시:

  • byteflix-plus-platform-ops byteflix-plus-prod-k8s 플릿으로만 범위가 지정된 Fleet manager 역할을 부여받았습니다
  • bbs-platform-ops bbs-prod-k8s 플릿으로만 범위가 지정된 Fleet manager 역할을 부여받았습니다

결과: ByteFlix+ 팀은 ByteFlix+ 플릿에서만 작업할 수 있고, BBS 팀은 BBS 플릿에서만 작업할 수 있습니다.

제한 사항: 이를 위해서는 Authentication domain manager이(가) Fleet permissions UI를 통해 초기 액세스 권한 부여를 설정해야 합니다. 설정된 후에는 유닛 리더가 중앙 IT 부서의 개입 없이 새로운 플릿에 대한 액세스 권한을 부여할 수 없습니다.

참조: 기본 패턴.

패턴 2: 사용자 지정 수명 주기 역할

해결 방법: 플랫폼 운영팀이 플릿을 구성하고 앱 팀이 배포하는 수명 주기 분리.

작동 방식: Fleet을(를) 대상으로 하는 두 개의 사용자 지정 엔티티 범위 역할을 생성합니다:

  • 플랫폼 운영 팀에 할당되고 Modify을(를) 포함하는 플릿 작성자
  • 플릿 배포자, Deploy을(를) 보유하며 앱 팀 및 계약자에게 할당됨

그런 다음 패턴 1을 사용하여 특정 플릿 엔티티의 그룹에 두 역할이 모두 부여됩니다.

결과: 플랫폼 운영팀은 소유한 플릿을 구성하고, 앱 팀은 배포를 실행하며, 어느 쪽도 플릿을 삭제할 수 없습니다.

제한 사항: 사용자 지정 역할을 생성하려면 Pro 또는 엔터프라이즈 에디션이 필요합니다. 플릿에 이를 부여하려면 Fleet permissions UI를 통해 Authentication domain manager이(가) 필요합니다.

참조: 고급 패턴.

패턴 3: 그룹 관리자 위임

해결 방법: Authentication domain manager 없는 계약자 위임.

작동 방식: 단위 리더에게 해당 단위의 운영 그룹으로 범위가 지정된 Group admin 역할을 부여합니다.

ByteFlix+의 예:

  • 그룹: byteflix-plus-bu-leads
  • 역할: Group admin
  • 범위: byteflix-plus-platform-ops의 멤버십을 관리할 수 있으며 byteflix-plus-app-teams

결과: 단위 리더는 중앙 IT를 거치지 않고 Authentication domain manager없이도 그룹에서 계약자를 추가하고 제거할 수 있습니다.

제한 사항: 부서 리더는 그룹에 누가 속해 있는지 관리할 수 있지만, 새로운 액세스 부여를 생성하거나 새 플릿에 그룹을 할당할 수는 없습니다. 새 플릿이 생성되면 중앙 IT 부서에서 여전히 해당 플릿에 대한 액세스 부여를 생성해야 합니다.

참조: 엔터프라이즈 패턴.

결합된 RBAC 아키텍처

단일 조직 내에서 세 가지 패턴을 모두 함께 사용하면 ByteFlix의 아키텍처는 다음과 같습니다:

Organization: ByteFlix Entertainment
├── ByteFlix+ (Streaming BU):
│ ├── Groups:
│ │ ├── byteflix-plus-bu-leads (Group admin over operational groups)
│ │ ├── byteflix-plus-platform-ops (Fleet author role)
│ │ └── byteflix-plus-app-teams (Fleet deployer role, includes contractors)
│ └── Fleets (entity-scoped to ByteFlix+ groups only):
│ ├── byteflix-plus-prod-k8s
│ └── byteflix-plus-stage-k8s
│
├── BBS (Broadcast BU):
│ ├── Groups:
│ │ ├── bbs-bu-leads (Group admin)
│ │ ├── bbs-platform-ops (Fleet author role)
│ │ └── bbs-app-teams (Fleet deployer role)
│ └── Fleets (entity-scoped to BBS groups only):
│ ├── bbs-prod-k8s
│ └── bbs-stage-k8s
│
└── PixelTV (Cable BU):
├── Groups:
│ ├── pixeltv-bu-leads (Group admin)
│ ├── pixeltv-platform-ops (Fleet author role)
│ └── pixeltv-app-teams (Fleet deployer role)
└── Fleets (entity-scoped to PixelTV groups only):
├── pixeltv-prod-k8s
└── pixeltv-stage-k8s
Custom entity-scoped roles, created once by central IT:
├── Fleet author (Modify)
└── Fleet deployer (Deploy)

RBAC 트레이드오프

장점:

  • 조직 개편이 필요하지 않음
  • 단일 계약 및 청구 관계
  • 올바르게 설정된 권한 부여를 통해 부서 간의 운영 분리를 달성합니다.

단점:

  • 중앙 IT 부서의 초기 설정이 필요하며, 이는 인증 도메인 관리자의 개입을 의미합니다.
  • 새로운 플릿은 여전히 중앙 IT 부서에서 액세스 권한 부여를 생성해야 하므로 지속적인 종속성이 발생합니다.
  • 별도의 조직보다 더 복잡한 권한 모델입니다.
  • 분리는 올바른 액세스 권한 부여 설정에 따라 달라지며, 조직 경계에 의해 강제되지 않습니다.

이 모델은 플릿을 볼 수 있는 사람이 아니라 플릿에서 작업할 수 있는 사람을 제어합니다.

플릿 범위 역할에는 Read 권한이 없으므로, Fleet Control에서 작업하는 모든 사용자는 조직 범위의 읽기 액세스 권한이 필요합니다. ByteFlix+ 사용자는 BBS 및 PixelTV 플릿에 대해 작업을 수행할 수는 없지만, 해당 플릿이 존재한다는 것을 볼 수 있습니다.

비즈니스 단위가 서로의 플릿을 전혀 볼 수 없어야 하는 경우, 별도의 조직만이 이를 제공하는 유일한 모델입니다.

역할 요구 사항

동작필요한 역할빈도Notes
초기 Agent Control 설정인증 도메인 관리자1회시스템 ID를 생성하고 권한을 할당합니다.
플릿 생성/업데이트조직 제품 관리자진행 중User 그룹에 자동 할당됨
설정 생성조직 제품 관리자진행 중User 그룹에 자동 할당됨
플릿 배포조직 관리자 또는 플릿별 플릿 관리자진행 중기본 Admin 그룹에 자동 할당됩니다. 또는 배포가 포함된 플릿 범위의 역할을 사용하십시오.
플릿 및 배포 삭제조직 관리자 또는 플릿별 플릿 관리자비정기적설정 삭제에는 조직 수준의 범위가 필요합니다.
설정 승인, 승인 정책 설정조직 관리자진행 중조직 범위 전용, 플릿별로 범위를 지정할 수 없습니다.
액세스 권한 생성인증 도메인 관리자새 플릿당사용자 그룹을 플릿에 할당합니다.
그룹 멤버십 관리그룹 관리자, 위임됨진행 중전체 도메인 관리자 권한 없이 멤버십을 관리합니다. 패턴 3참조

역할은 추가되므로 여러 역할을 보유한 사용자는 해당 권한의 합계를 갖습니다. 각 표준 역할이 다루는 내용에 대한 자세한 내용은 사용자 관리 개념을 참조하십시오.

알려진 이슈 및 해결 방법

역할 ID를 직접 쿼리할 수 없습니다.

문제: NerdGraph은(는) 이름으로 역할 ID를 나열하는 직접적인 쿼리를 제공하지 않습니다.

해결 방법: 이미 역할을 보유한 그룹에서 읽어옵니다:

{
actor {
organization {
authorizationManagement {
authenticationDomains(id: "YOUR_AUTH_DOMAIN_ID") {
authenticationDomains {
groups {
groups {
displayName
roles {
roles {
roleId
displayName
}
}
}
}
}
}
}
}
}
}

플릿 GUID 찾기

문제: UI를 통해 플릿 GUID를 쉽게 찾을 수 없습니다.

해결 방법: 플릿 세부 정보 페이지로 이동하십시오. GUID는 URL의 /fleets/ 뒤에 있습니다. 대신 플릿을 쿼리하려면 NerdGraph Fleet Control 튜토리얼을 참조하십시오.

빠른 참조: NerdGraph ID 찾기

조직 및 인증 도메인 ID:

{
actor {
organization {
id
name
userManagement {
authenticationDomains {
authenticationDomains {
id
name
}
}
}
}
}
}

그룹 ID:

{
actor {
organization {
userManagement {
authenticationDomains(id: "YOUR_AUTH_DOMAIN_ID") {
authenticationDomains {
groups {
groups {
id
displayName
}
}
}
}
}
}
}
}

계정 ID: 뉴렐릭 URL에 표시되거나:

{
actor {
accounts {
id
name
}
}
}

자동화 스크립트 템플릿

대규모로 여러 플릿과 그룹을 관리하는 팀을 위해 뉴렐릭 CLI를 사용하는 템플릿이 있습니다. 그룹을 생성하고, 플릿을 생성하며, 해당 플릿에 대한 그룹 액세스 권한을 부여합니다.

고급 패턴에 설명된 대로 먼저 UI에서 사용자 지정 역할을 생성하고, 역할 ID를 스크립트에 전달하십시오.

bash
$
#!/bin/bash
$
set -euo pipefail
$
$
# Prerequisites:
$
# - New Relic CLI installed and profile configured with a user key
$
# - The Authentication domain manager role, required to create access grants
$
# - A role created in Administration > Access management > Roles, and its ID
$
$
AUTH_DOMAIN_ID="YOUR_AUTH_DOMAIN_ID"
$
ACCOUNT_ID="YOUR_ACCOUNT_ID"
$
ROLE_ID="YOUR_ROLE_ID"
$
GROUP_NAME="fleet-architects"
$
FLEET_NAME="production-us-east-k8s"
$
$
# 1. Create the group. Note the returned group ID.
$
echo "Creating group ${GROUP_NAME}..."
$
newrelic nerdgraph query 'mutation CreateGroup($authDomainId: ID!, $displayName: String!) {
$
userManagementCreateGroup(createGroupOptions: {
$
authenticationDomainId: $authDomainId
$
displayName: $displayName
$
}) {
$
group { id displayName }
$
}
$
}' --variables "{\"authDomainId\": \"${AUTH_DOMAIN_ID}\", \"displayName\": \"${GROUP_NAME}\"}"
$
$
# 2. Create the fleet. Note the returned fleet GUID.
$
echo "Creating fleet ${FLEET_NAME}..."
$
newrelic nerdgraph query 'mutation CreateFleet($name: String!, $scopeId: ID!) {
$
fleetControlCreateFleet(fleetEntity: {
$
name: $name
$
description: "Created by setup script"
$
managedEntityType: KUBERNETESCLUSTER
$
scope: { type: ACCOUNT, id: $scopeId }
$
}) {
$
entity { id name }
$
}
$
}' --variables "{\"name\": \"${FLEET_NAME}\", \"scopeId\": \"${ACCOUNT_ID}\"}"
$
$
# 3. Grant the group access to the fleet, using the IDs returned above.
$
GROUP_ID="GROUP_ID_FROM_STEP_1"
$
FLEET_GUID="FLEET_GUID_FROM_STEP_2"
$
$
echo "Granting entity-scoped access..."
$
newrelic nerdgraph query 'mutation GrantFleetAccess($groupId: ID!, $fleetGuid: ID!, $roleId: ID!) {
$
authorizationManagementGrantAccess(grantAccessOptions: {
$
grantee: { type: GROUP, id: $groupId }
$
entityAccessGrants: {
$
entity: { id: $fleetGuid, type: "fleet" }
$
roleId: $roleId
$
}
$
}) {
$
accessGrants { id }
$
}
$
}' --variables "{\"groupId\": \"${GROUP_ID}\", \"fleetGuid\": \"${FLEET_GUID}\", \"roleId\": \"${ROLE_ID}\"}"
$
$
echo "Setup complete."

수동으로 쿼리 문자열을 작성하는 대신 --variables을(를) 사용하여 값을 전달하여 공백이나 따옴표가 포함된 이름이 요청을 중단시키지 않도록 하십시오. 무인으로 단계를 실행하려면 각 응답을 캡처하고 다음 호출 전에 해당 응답에서 ID를 읽으십시오.

플릿 업데이트 및 삭제, 배포 관리를 포함한 더 많은 플릿 작업에 대해서는 Fleet Control API 및 CLI를 참조하십시오.

무엇 향후 계획

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.