Documentation

32. 보안

다음 섹션은 |at|에서 파일 시스템 보안을 처리하고 사용자가 제어하도록 하는 방법을 이해하는 데 도움이 됩니다.

모든 플레이북은 awx 파일 시스템 사용자를 통해 실행됩니다. 실행 중인 작업의 경우 |at|는 Linux 컨테이너를 사용하여 작업을 격리합니다. 이러한 프로젝션을 통해 작업은 해당 작업 템플릿의 프로젝트 디렉터리에 있는 플레이북, 역할, 데이터에만 액세스할 수 있습니다.

인증 정보 보안의 경우 사용자가 잠긴 SSH 키를 업로드하고 잠금 해제 암호를 《묻기》로 설정하도록 선택할 수 있습니다. 또한 SSH 인증 정보나 sudo 암호를 데이터베이스에 저장하는 대신 사용자에게 묻는 메시지를 표시하도록 선택할 수도 있습니다.

32.1. 플레이북 액세스 및 정보 공유

|At|에서 자동화 실행 환경 및 Linux 컨테이너를 사용하면 플레이북에서 프로젝트 디렉터리 외부의 파일을 읽지 않습니다.

기본적으로 컨테이너 내부의 ansible-playbook 프로세스에 노출되는 데이터는 현재 사용 중인 프로젝트뿐입니다.

작업 설정에서 이를 사용자 지정하고 호스트에서 컨테이너에 추가 디렉터리를 노출할 수 있습니다. 자세한 내용은 다음 섹션, :ref:`ug_isolation`를 참조하십시오.

32.1.1. 격리 기능 및 변수

|At|에서는 컨테이너 기술을 사용하여 각 작업을 격리합니다. 기본적으로 현재 프로젝트만 작업 템플릿을 실행하는 컨테이너에 노출됩니다.

추가 디렉터리를 노출하도록 플레이북 실행을 사용자 지정해야 할 수도 있습니다. 작업 격리 사용을 미세 조정하기 위해 설정할 수 있는 특정 변수가 있습니다.

기본적으로 |at|에서는 시스템의 tmp 디렉터리(기본적으로 /tmp)를 스테이징 영역으로 사용합니다. 작업 설정 화면의 작업 실행 경로 필드 또는 ``/api/v2/settings/jobs``의 REST API에서 이 설정을 변경할 수 있습니다.

AWX_ISOLATION_BASE_PATH = "/opt/tmp"

구체적으로 호스트에서 플레이북이 실행되는 컨테이너로 노출되어야 하는 추가 디렉터리가 있는 경우 작업 설정 화면의 격리된 작업에 노출된 경로 필드 또는 ``/api/v2/settings/jobs``의 REST API에서 지정할 수 있습니다.

AWX_ISOLATION_SHOW_PATHS = ['/list/of/', '/paths']

참고

플레이북에서 경로에 정의된 키 또는 설정을 사용해야 하는 경우 AWX_ISOLATION_SHOW_PATHS``에 ``/var/lib/awx/.ssh 파일을 추가하는 것이 좋습니다.

위의 필드는 작업 설정 창에서 찾을 수 있습니다.

_images/configure-tower-jobs-isolated-jobs-fields.png

32.2. 역할 기반 액세스 제어

|at|에는 역할 기반 액세스 제어(RBAC)가 내장되어 있어 관리자가 서버 인벤토리, 조직 등에 대한 액세스 권한을 위임할 수 있습니다. 관리자는 또한 다양한 인증 정보 관리를 중앙 집중화하여 최종 사용자가 해당 시크릿을 최종 사용자에게 노출하지 않고도 필요한 시크릿을 활용하도록 할 수 있습니다. 컨트롤러는 RBAC 제어를 통해 보안을 강화하고 관리를 간소화할 수 있습니다.

RBAC는 특정 기능이 설정되는 《오브젝트》를 보거나 변경하거나 삭제할 수 있는 사람 또는 대상을 정확하게 정의하는 역할의 관점에서 생각하는 것이 가장 쉽습니다. RBAC는 사용자 또는 팀에 역할을 부여하는 방식에 해당합니다.

|at|의 RBAC 설계와 관련하여 숙지해야 하는 몇 가지 기본 개념(역할, 리소스, 사용자)이 있습니다. 사용자는 역할의 멤버가 될 수 있으며, 역할은 해당 역할과 연결된 리소스 또는 《하위》 역할과 연결된 리소스에 대한 특정 액세스 권한을 부여합니다.

역할은 기본적으로 기능 컬렉션입니다. 이러한 기능과 컨트롤러의 리소스에 대한 액세스 권한은 사용자에게 할당된 역할이나 역할 계층 구조에서 상속된 역할을 통해 사용자에게 부여됩니다.

역할은 기능 그룹을 사용자 그룹과 연결합니다. 모든 기능은 역할 내의 멤버십에서 파생됩니다. 사용자는 할당된 역할이나 역할 계층 구조를 통해 상속된 역할을 통해서만 기능을 받습니다. 역할의 모든 멤버는 해당 역할에 부여된 모든 기능을 수행할 수 있습니다. 역할은 조직 내에서 비교적 안정적이지만 사용자와 기능은 둘 다 다양하고 빠르게 변경될 수 있습니다. 사용자는 다수의 역할을 가질 수 있습니다.

32.2.1. 역할 계층 구조 및 액세스 권한 상속

《SomeCompany》라는 조직을 보유하고 있고, 《Josie》와 《Carter》라는 두 직원에게 해당 조직과 관련된 모든 설정을 관리할 수 있는 액세스 권한을 부여하려고 하는 상황을 가정해 보겠습니다. 두 사람 모두 조직의 admin_role 멤버로 만들어야 합니다.

user-role-relationship

일반적으로 시스템에는 많은 역할이 있고, 일부 역할에 다른 역할의 기능이 모두 포함되기를 원합니다. 예를 들어, 시스템 관리자는 조직 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있고, 조직 관리자는 프로젝트 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있기를 원할 수 있습니다.

이러한 개념을 〈역할 계층’이라고 합니다.

  • 상위 역할에는 모든 하위 역할에 부여된 모든 기능이 제공됩니다.

  • 역할의 멤버에게는 멤버로 속한 역할과 모든 하위 역할의 모든 기능이 자동으로 제공됩니다.

역할 계층은 역할에 《상위 역할》이 포함되도록 허용하는 방식으로 표현합니다. 역할에 포함된 모든 기능은 모든 상위 역할(또는 해당 상위의 상위 등)에 암시적으로 부여됩니다.

rbac-role-hierarchy

일반적으로 시스템에는 많은 역할이 있고, 일부 역할에 다른 역할의 기능이 모두 포함되기를 원합니다. 예를 들어, 시스템 관리자는 조직 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있고, 조직 관리자는 프로젝트 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있기를 원할 수 있습니다. 이러한 개념을 《역할 계층》이라고 하며, 역할 계층은 역할에 《상위 역할》이 포함되도록 허용하는 방식으로 표현합니다. 역할에 포함된 모든 기능은 모든 상위 역할(또는 해당 상위의 상위 등)에 암시적으로 부여됩니다. 물론 역할에는 상위가 두 개 이상 있을 수 있으며, 기능은 모든 상위에 암시적으로 부여됩니다.

rbac-heirarchy-morecomplex

또한 RBAC 제어 방식을 사용하면 사용자 및 사용자 팀이 특정 호스트 세트에 대해 플레이북을 실행하도록 명시적으로 허용할 수 있습니다. 사용자와 팀은 기능이 부여된 플레이북 및 호스트 세트에 한해 실행할 수 있습니다. 또한 |at|를 사용하면 사용자와 팀을 필요한 만큼 생성하거나 가져올 수 있습니다. 즉, 사용자와 팀을 수동으로 생성하거나 LDAP 또는 Active Directory에서 가져올 수 있습니다.

RBAC는 특정 기능이 결정되는 《오브젝트》를 보거나 변경하거나 삭제할 수 있는 사람 또는 대상의 관점에서 생각하는 것이 가장 쉽습니다.

32.2.2. RBAC 적용

다음 섹션에서는 사용자 환경에 |at|의 RBAC 시스템을 적용하는 방법을 다룹니다.

32.2.2.1. 사용자 편집

사용자를 편집할 때 automation controller 시스템 관리자는 사용자를 시스템 관리자*(슈퍼유저라고도 함) 또는 *시스템 감사자 중 하나로 지정할 수 있습니다.

  • 시스템 관리자는 automation controller 환경 내의 모든 오브젝트에 대한 모든 기능(읽기/쓰기/실행)을 암시적으로 상속합니다.

  • 시스템 감사자는 automation controller 환경 내의 모든 오브젝트에 대한 읽기 전용 기능을 암시적으로 상속합니다.

32.2.2.2. 조직 편집

시스템 관리자는 조직을 편집할 때 다음 역할을 지정할 수 있습니다.

  • 한 명 이상의 사용자를 조직 관리자로 지정

  • 한 명 이상의 사용자를 조직 감사자로 지정

  • 한 명 이상의 사용자(또는 팀)를 조직 멤버로 지정

조직의 멤버인 사용자/팀은 조직 관리자를 볼 수 있습니다.

조직 관리자인 사용자는 해당 automation controller 조직 내의 모든 오브젝트에 대한 모든 기능을 암시적으로 상속합니다.

조직 감사자인 사용자는 해당 automation controller 조직 내의 모든 오브젝트에 대한 읽기 전용 기능을 암시적으로 상속합니다.

32.2.2.3. 조직의 프로젝트 편집

시스템 관리자 및 조직 관리자는 자신이 관리자로 속해 있는 조직에서 프로젝트를 편집할 때 다음을 지정할 수 있습니다.

  • 프로젝트 관리자에 해당하는 하나 이상의 사용자/팀

  • 프로젝트 멤버에 해당하는 하나 이상의 사용자/팀

  • 해당 조직의 멤버에 해당하는 사용자/팀 중 SCM에서 프로젝트를 업데이트할 수 있는 하나 이상의 사용자/팀

프로젝트 멤버에 해당하는 사용자는 프로젝트 관리자를 볼 수 있습니다.

프로젝트 관리자는 SCM에서 프로젝트를 업데이트하는 기능을 암시적으로 상속합니다.

또한 관리자는 (해당 프로젝트의 멤버인 사용자/팀 중) 작업 템플릿에서 해당 프로젝트를 사용할 수 있는 사용자/팀을 하나 이상 지정할 수도 있습니다.

32.2.2.4. 조직 내에서 인벤토리 및 인증 정보 생성

인증 정보를 사용하거나 읽거나 쓸 수 있도록 부여하는 모든 액세스 권한이 이제 역할을 통해 처리됩니다. 인증 정보에 더 이상 ‘팀’ 또는 ‘사용자’를 설정하지 않습니다. 대신 |at|의 RBAC 시스템을 사용하여 소유권, 감사자 또는 사용 역할을 부여합니다.

시스템 관리자와 조직 관리자는 관리 기능에 따라 조직 내에서 인벤토리 및 인증 정보를 생성할 수도 있습니다.

인벤토리를 편집하든 인증 정보를 편집하든 시스템 관리자와 조직 관리자는 (해당 조직의 멤버인 사용자/팀 중에서) 해당 인벤토리 또는 인증 정보를 사용할 수 있는 기능을 제공할 사용자/팀을 하나 이상 지정할 수 있습니다.

시스템 관리자와 조직 관리자는 (해당 조직의 멤버인 사용자/팀 중에서) (동적 또는 수동으로) 인벤토리를 업데이트할 수 있는 사용자/팀을 하나 이상 지정할 수 있습니다. 관리자는 인벤토리에 임시 명령을 실행할 수도 있습니다.

32.2.2.5. 작업 템플릿 편집

시스템 관리자, 조직 관리자, 프로젝트 관리자는 자신에게 제공되는 관리 기능에 따라 프로젝트 내에서 해당 프로젝트에 대해 새 작업 템플릿을 생성하고 수정할 수 있습니다.

작업 템플릿을 편집할 때 관리자(automation controller, 조직, 프로젝트)는 자신이 사용할 수 있는 조직의 인벤토리 및 인증 정보 중에서 선택하거나, 런타임 시 선택되도록 해당 필드를 비워 둘 수 있습니다.

또한 (해당 프로젝트의 멤버인 사용자/팀 중) 해당 작업 템플릿을 실행할 수 있는 사용자/팀을 하나 이상 지정할 수 있습니다. 작업 템플릿에 지정된 인벤토리 또는 인증 정보에 대해 사용자/팀에 부여된 명시적 기능과 관계없이 실행 기능은 유효합니다.

32.2.2.6. 사용자 뷰

사용자는 다음을 수행할 수 있습니다.

  • 멤버로 속한 모든 조직 또는 프로젝트 보기

  • 자신에게만 해당하는 자체 인증 정보 오브젝트 생성

  • 실행 기능이 부여된 모든 작업 템플릿 참조 및 실행

사용자에게 실행 기능이 제공된 작업 템플릿에서 인벤토리 또는 인증 정보를 지정하지 않는 경우, 런타임에 사용자에게 사용자가 소유하거나 사용 기능이 있는 조직의 인벤토리 및 인증 정보 중에서 선택하라는 메시지가 표시됩니다.

작업 템플릿 관리자인 사용자는 작업 템플릿을 변경할 수 있습니다. 그러나 작업 템플릿에 사용된 인벤토리, 프로젝트, 플레이북 또는 인증 정보를 변경하려면 사용자에게 현재 사용 중이거나 설정 중인 프로젝트 및 인벤토리에 대한 ‘사용’ 역할도 있어야 합니다.

32.2.3. 역할

이 문서의 앞부분에서 설명한 것처럼 인증 정보를 사용하거나 읽거나 쓸 수 있도록 부여하는 모든 액세스 권한이 이제 역할을 통해 처리되며, 역할은 리소스에 대해 정의됩니다.

32.2.3.1. 기본 제공 역할

다음 테이블에는 RBAC 시스템 역할과 해당 역할이 |at|의 권한과 관련하여 정의되는 방법에 대한 간략한 설명이 있습니다.

시스템 역할

수행할 수 있는 작업

시스템 관리자 - 시스템 수준 싱글톤

시스템의 모든 측면 관리

시스템 감사자 - 시스템 수준 싱글톤

시스템의 모든 측면 보기

임시 역할 - 인벤토리

인벤토리에서 임시 명령 실행

관리자 역할 - 조직, 팀, 인벤토리, 프로젝트, 작업 템플릿

정의된 조직, 팀, 인벤토리, 프로젝트 또는 작업 템플릿의 모든 측면 관리

감사자 역할 - 모두

정의된 조직, 프로젝트, 인벤토리 또는 작업 템플릿의 모든 측면 보기

실행 역할 - 작업 템플릿

할당된 작업 템플릿 실행

멤버 역할 - 조직, 팀

해당 조직 또는 팀과 관련된 모든 설정을 관리

읽기 역할 - 조직, 팀, 인벤토리, 프로젝트, 작업 템플릿

정의된 조직, 팀, 인벤토리, 프로젝트 또는 작업 템플릿의 모든 측면 보기

업데이트 역할 - 프로젝트

구성된 소스 제어 관리 시스템에서 프로젝트 업데이트

업데이트 역할 - 인벤토리

클라우드 소스 업데이트 시스템을 사용하여 인벤토리 업데이트

소유자 역할 - 인증 정보

이 인증 정보의 모든 측면 소유 및 관리

사용 역할 - 인증 정보, 인벤토리, 프로젝트

작업 템플릿의 인증 정보, 인벤토리 또는 프로젝트 사용

싱글톤 역할은 시스템 전체에 대한 권한을 부여하는 특수 역할입니다. |at|는 현재 두 가지 기본 제공 싱글톤 역할을 제공하고 있지만, 싱글톤 역할을 생성하거나 사용자 정의하는 기능은 지원하지 않습니다.

32.2.3.2. 일반적인 팀 역할 - 《사용자》

일반적으로 Automation controller 지원 담당자는 컨트롤러를 사용할 수 있도록 유지하고 지원 가능성과 사용자의 사용 편의성 사이의 균형을 유지하며 관리합니다. automation controller 지원에서는 종종 사용자가 새 조직을 생성하고 해당 팀의 멤버에게 필요한 해당 액세스 권한을 추가할 수 있도록 사용자에게 ‘조직 소유자/관리자’를 할당합니다. 이를 통해 개인 지원을 최소화하고 서비스 가동 시간 유지와 |at|을/를 사용하는 사용자 지원에 더 중점을 둘 수 있습니다.

다음은 automation controller 조직에서 관리하는 몇 가지 일반적인 역할입니다.

시스템 역할
(조직의 경우)
일반 사용자
역할
설명
소유자
팀 리더 -
기술 리더
이 사용자는 조직의 다른 사용자가 액세스하는 권한을 제어할 수 있습니다.
프로젝트, 인벤토리, 작업 템플릿에 대한 특정 액세스 권한을 추가/제거하고 사용자에게 부여할 수 있습니다.
또한 이 사용자는 조직의 프로젝트, 템플릿, 인벤토리, 팀, 인증 정보에 걸친 모든 측면을
생성/제거/수정할 수 있습니다.
감사자
보안 엔지니어 -
프로젝트 관리자
이 계정은 읽기 전용 모드로 조직의 모든 측면을 볼 수 있습니다.
따라서 규정 준수를 확인하고 유지하는 사용자에게 유용할 수 있습니다.
또한 이 역할은 |at|의 작업 데이터를 관리하거나 일부 다른 데이터 수집기로
전송하는 서비스 계정에 유용할 수도 있습니다.
멤버 -
팀
기타 모든 사용자
이러한 사용자는 기본적으로 조직 멤버이며, 조직의 어떤 측면에도
액세스할 수 없습니다. 이러한 사용자에게 액세스 권한을 부여하려면 각 조직 소유자가
각 팀에 이들 사용자를 추가하고, 조직의 프로젝트, 인벤토리, 작업 템플릿의 각 구성 요소에 대한
관리, 실행, 사용, 업데이트, 임시 권한을 부여해야 합니다.
멤버 -
팀 ‘소유자’
고급 사용자 -
주요 개발자
조직 소유자는 팀 인터페이스를 통해 프로젝트, 인벤토리, 작업 템플릿을 포함한 모든
조직 구성 요소를 담당하는 ‘관리자’를 제공할 수 있습니다. 이러한 사용자는
액세스 권한을 부여받은 각 구성 요소를 수정하고 활용할 수 있습니다.
멤버 -
팀 ‘실행’
개발자 -
엔지니어
가장 일반적인 역할로, 조직 멤버가 작업 템플릿을 실행하고 특정 구성 요소에 대한 권한을
읽을 수 있도록 허용합니다. 이 역할은 템플릿에 적용되는 권한에 해당합니다.
멤버 -
팀 ‘사용’
개발자 -
엔지니어
이 권한은 조직의 인증 정보, 인벤토리, 프로젝트에 적용됩니다.
이 권한은 사용자가 작업 템플릿 내의 각 구성 요소를 사용할 수 있도록 허용합니다.
멤버 -
팀 ‘업데이트’
개발자 -
엔지니어
이 권한은 프로젝트에 적용됩니다. 사용자가 프로젝트에서 SCM 업데이트를 실행할 수 있도록 허용합니다.

32.3. 역할의 기능: 편집 및 생성

automation controller 3.3에는 워크플로우와 같은 특정 리소스 유형과 관련된 조직의 ‘리소스 역할’ 기능이 새롭게 도입되었습니다. 이러한 역할의 멤버가 되면 일반적으로 두 가지 유형의 권한이 제공됩니다. 워크플로우의 경우 사용자에게 조직 《Default》에 대한 《워크플로우 관리자 역할》이 제공됩니다.

  • 이 사용자는 조직 《Default》에 새 워크플로우를 생성할 수 있습니다.

  • 사용자는 《Default》 조직의 모든 워크플로우를 편집할 수 있습니다.

한 가지 예외는 역할을 갖는 것이 생성 권한과 관련이 없는 작업 템플릿입니다(자세한 내용은 자체 섹션 참조).

32.3.1. 리소스 역할 및 조직 멤버 역할의 독립성

리소스별 조직 역할은 조직 역할인 관리자 및 멤버와 독립적입니다. 《Default》 조직에 대한 《워크플로우 관리자 역할》이 있다고 해서 사용자가 조직의 모든 사용자를 볼 수 있는 것은 아니지만, 《Default》 조직에서 《멤버》 역할이 있으면 볼 수 있습니다. 두 가지 유형의 역할은 서로 독립적으로 위임됩니다.

32.3.1.1. 작업 템플릿을 편집하는 데 필요한 권한

작업 실행에 영향을 미치지 않는 필드(민감하지 않은 필드)의 경우 사용자는 작업 템플릿 관리자 역할만으로도 필드를 편집할 수 있습니다. 그러나 작업 템플릿에서 작업 실행에 영향을 미치는 필드를 편집하려면 사용자에게 다음이 필요합니다.

  • 작업 템플릿에 대한 관리자 역할

  • 관련 프로젝트에 대한 사용 역할

  • 관련 인벤토리에 대한 사용 역할

《조직 작업 템플릿 관리자》 역할이 도입되었지만 작업 템플릿에서 사용하는 프로젝트/인벤토리에 대한 사용 역할이 없는 경우 이 역할만으로는 조직 내 작업 템플릿을 편집하기에 충분하지 않습니다.

(조직 내) 전체 작업 템플릿 제어를 사용자 또는 팀에 위임하려면 팀 또는 사용자에게 세 가지 조직 수준 역할을 모두 부여해야 합니다.

  • 작업 템플릿 관리자

  • 프로젝트 관리자

  • 인벤토리 관리자

그러면 사용자(또는 이러한 역할이 있는 팀의 멤버인 모든 사용자)에게 조직의 작업 템플릿을 수정할 수 있는 전체 액세스 권한이 부여됩니다. 작업 템플릿에서 다른 조직의 인벤토리나 프로젝트를 사용하는 경우 이러한 조직 역할의 사용자가 여전히 해당 작업 템플릿을 수정할 권한이 없을 수 있습니다. 권한을 명확하게 관리하기 위해 다른 조직의 프로젝트/인벤토리를 혼합하지 않는 것이 가장 좋습니다.

32.3.1.2. RBAC 권한

각 역할에는 콘텐츠 오브젝트가 있어야 합니다(예: 조직 관리자 역할에는 조직의 콘텐츠 오브젝트가 있음). 역할을 위임하려면 사용자 암호를 재설정할 수 있는 일부 예외를 제외하고 콘텐츠 오브젝트에 대한 관리자 권한이 필요합니다.

**상위**는 해당 조직입니다.

**허용**은 이 새 권한이 명시적으로 허용하는 항목입니다.

**범위**는 이 새 역할이 생성될 상위 리소스입니다. 예를 들면 ``Organization.project_create_role``입니다.

리소스 생성자에게 해당 리소스에 대한 관리자 역할을 부여해야 한다고 가정하고 있습니다. 리소스 생성이 리소스 관리를 의미하지는 않는 인스턴스가 있는 경우 명시적으로 호출됩니다.

다음은 각 관리자 유형과 연결된 규칙입니다.

프로젝트 관리자

  • 허용: 모든 프로젝트의 생성, 읽기, 업데이트, 삭제

  • 범위: 조직

  • 사용자 인터페이스: 프로젝트 추가 화면 - 조직

인벤토리 관리자

  • 상위: 조직 관리자

  • 허용: 인벤토리 생성, 읽기, 업데이트, 삭제

  • 범위: 조직

  • 사용자 인터페이스: 인벤토리 추가 화면 - 조직

참고

사용 역할과 마찬가지로 사용자에게 프로젝트 관리자 및 인벤토리 관리자 역할을 부여하면 사용자가 조직의 작업 템플릿(워크플로우 아님)을 생성할 수 있습니다.

인증 정보 관리자

  • 상위: 조직 관리자

  • 허용: 공유 인증 정보의 생성, 읽기, 업데이트, 삭제

  • 범위: 조직

  • 사용자 인터페이스: 인증 정보 추가 화면 - 조직

알림 관리자

  • 상위: 조직 관리자

  • 허용: 알림 할당

  • 범위: 조직

워크플로우 관리자

  • 상위: 조직 관리자

  • 허용: 워크플로우 생성

  • 범위: 조직

조직 실행

  • 상위: 조직 관리자

  • 허용: JT 및 WFJT 실행

  • 범위: 조직

다음은 조직과 해당 역할 그리고 각 역할이 액세스할 수 있는 리소스를 보여주는 샘플 시나리오입니다.

_images/rbac-multiple-resources-scenario.png