31. 보안¶
다음 섹션은 |at|에서 파일 시스템 보안을 처리하고 사용자가 제어하도록 하는 방법을 이해하는 데 도움이 됩니다.
모든 플레이북은 awx 파일 시스템 사용자를 통해 실행됩니다. 실행 중인 작업의 경우 |at|는 Linux 컨테이너를 사용하여 작업을 격리합니다. 이러한 프로젝션을 통해 작업은 해당 작업 템플릿의 프로젝트 디렉터리에 있는 플레이북, 역할, 데이터에만 액세스할 수 있습니다.
인증 정보 보안의 경우 사용자가 잠긴 SSH 키를 업로드하고 잠금 해제 암호를 《묻기》로 설정하도록 선택할 수 있습니다. 또한 SSH 인증 정보나 sudo 암호를 데이터베이스에 저장하는 대신 사용자에게 묻는 메시지를 표시하도록 선택할 수도 있습니다.
31.1. 플레이북 액세스 및 정보 공유¶
|At|에서 자동화 실행 환경 및 Linux 컨테이너를 사용하면 플레이북에서 프로젝트 디렉터리 외부의 파일을 읽지 않습니다.
기본적으로 컨테이너 내부의 ansible-playbook 프로세스에 노출되는 데이터는 현재 사용 중인 프로젝트뿐입니다.
You can customize this in the Job Settings and expose additional directories from the host into the container. Refer the next section, 격리 기능 및 변수 for more information.
31.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파일을 추가하는 것이 좋습니다.
위의 필드는 작업 설정 창에서 찾을 수 있습니다.
31.2. 역할 기반 액세스 제어¶
Role-Based Access Controls (RBAC) are built into automation controller and allow administrators to delegate access to server inventories, organizations, and more. Administrators can also centralize the management of various credentials, allowing end users to leverage a needed secret without ever exposing that secret to the end user. RBAC controls allow the controller to help you increase security and streamline management.
RBAC는 특정 기능이 설정되는 《오브젝트》를 보거나 변경하거나 삭제할 수 있는 사람 또는 대상을 정확하게 정의하는 역할의 관점에서 생각하는 것이 가장 쉽습니다. RBAC는 사용자 또는 팀에 역할을 부여하는 방식에 해당합니다.
There are a few main concepts that you should become familiar with regarding automation controller’s RBAC design–roles, resources, and users. Users can be members of a role, which gives them certain access to any resources associated with that role, or any resources associated with 《descendant》 roles.
A role is essentially a collection of capabilities. Users are granted access to these capabilities and the controller’s resources through the roles to which they are assigned or through roles inherited through the role hierarchy.
역할은 기능 그룹을 사용자 그룹과 연결합니다. 모든 기능은 역할 내의 멤버십에서 파생됩니다. 사용자는 할당된 역할이나 역할 계층 구조를 통해 상속된 역할을 통해서만 기능을 받습니다. 역할의 모든 멤버는 해당 역할에 부여된 모든 기능을 수행할 수 있습니다. 역할은 조직 내에서 비교적 안정적이지만 사용자와 기능은 둘 다 다양하고 빠르게 변경될 수 있습니다. 사용자는 다수의 역할을 가질 수 있습니다.
31.2.1. 역할 계층 구조 및 액세스 권한 상속¶
《SomeCompany》라는 조직을 보유하고 있고, 《Josie》와 《Carter》라는 두 직원에게 해당 조직과 관련된 모든 설정을 관리할 수 있는 액세스 권한을 부여하려고 하는 상황을 가정해 보겠습니다. 두 사람 모두 조직의 admin_role 멤버로 만들어야 합니다.
일반적으로 시스템에는 많은 역할이 있고, 일부 역할에 다른 역할의 기능이 모두 포함되기를 원합니다. 예를 들어, 시스템 관리자는 조직 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있고, 조직 관리자는 프로젝트 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있기를 원할 수 있습니다.
이러한 개념을 〈역할 계층’이라고 합니다.
상위 역할에는 모든 하위 역할에 부여된 모든 기능이 제공됩니다.
역할의 멤버에게는 멤버로 속한 역할과 모든 하위 역할의 모든 기능이 자동으로 제공됩니다.
역할 계층은 역할에 《상위 역할》이 포함되도록 허용하는 방식으로 표현합니다. 역할에 포함된 모든 기능은 모든 상위 역할(또는 해당 상위의 상위 등)에 암시적으로 부여됩니다.
일반적으로 시스템에는 많은 역할이 있고, 일부 역할에 다른 역할의 기능이 모두 포함되기를 원합니다. 예를 들어, 시스템 관리자는 조직 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있고, 조직 관리자는 프로젝트 관리자가 액세스할 수 있는 모든 항목에 액세스할 수 있기를 원할 수 있습니다. 이러한 개념을 《역할 계층》이라고 하며, 역할 계층은 역할에 《상위 역할》이 포함되도록 허용하는 방식으로 표현합니다. 역할에 포함된 모든 기능은 모든 상위 역할(또는 해당 상위의 상위 등)에 암시적으로 부여됩니다. 물론 역할에는 상위가 두 개 이상 있을 수 있으며, 기능은 모든 상위에 암시적으로 부여됩니다.
RBAC controls also give you the capability to explicitly permit User and Teams of Users to run playbooks against certain sets of hosts. Users and teams are restricted to just the sets of playbooks and hosts to which they are granted capabilities. And, with automation controller, you can create or import as many Users and Teams as you require–create users and teams manually or import them from LDAP or Active Directory.
RBAC는 특정 기능이 결정되는 《오브젝트》를 보거나 변경하거나 삭제할 수 있는 사람 또는 대상의 관점에서 생각하는 것이 가장 쉽습니다.
31.2.2. RBAC 적용¶
The following sections cover how to apply automation controller’s RBAC system in your environment.
31.2.2.1. 사용자 편집¶
When editing a user, a automation controller system administrator may specify the user as being either a System Administrator (also referred to as the Superuser) or a System Auditor.
System administrators implicitly inherit all capabilities for all objects (read/write/execute) within the automation controller environment.
System Auditors implicitly inherit the read-only capability for all objects within the automation controller environment.
31.2.2.2. 조직 편집¶
시스템 관리자는 조직을 편집할 때 다음 역할을 지정할 수 있습니다.
한 명 이상의 사용자를 조직 관리자로 지정
한 명 이상의 사용자를 조직 감사자로 지정
한 명 이상의 사용자(또는 팀)를 조직 멤버로 지정
조직의 멤버인 사용자/팀은 조직 관리자를 볼 수 있습니다.
Users who are organization administrators implicitly inherit all capabilities for all objects within that automation controller organization.
Users who are organization auditors implicitly inherit the read-only capability for all objects within that automation controller organization.
31.2.2.3. 조직의 프로젝트 편집¶
시스템 관리자 및 조직 관리자는 자신이 관리자로 속해 있는 조직에서 프로젝트를 편집할 때 다음을 지정할 수 있습니다.
프로젝트 관리자에 해당하는 하나 이상의 사용자/팀
프로젝트 멤버에 해당하는 하나 이상의 사용자/팀
해당 조직의 멤버에 해당하는 사용자/팀 중 SCM에서 프로젝트를 업데이트할 수 있는 하나 이상의 사용자/팀
프로젝트 멤버에 해당하는 사용자는 프로젝트 관리자를 볼 수 있습니다.
프로젝트 관리자는 SCM에서 프로젝트를 업데이트하는 기능을 암시적으로 상속합니다.
또한 관리자는 (해당 프로젝트의 멤버인 사용자/팀 중) 작업 템플릿에서 해당 프로젝트를 사용할 수 있는 사용자/팀을 하나 이상 지정할 수도 있습니다.
31.2.2.4. 조직 내에서 인벤토리 및 인증 정보 생성¶
All access that is granted to use, read, or write credentials is now handled through roles. You no longer set the “team” or “user” for a credential. Instead, you use automation controller’s RBAC system to grant ownership, auditor, or usage roles.
시스템 관리자와 조직 관리자는 관리 기능에 따라 조직 내에서 인벤토리 및 인증 정보를 생성할 수도 있습니다.
인벤토리를 편집하든 인증 정보를 편집하든 시스템 관리자와 조직 관리자는 (해당 조직의 멤버인 사용자/팀 중에서) 해당 인벤토리 또는 인증 정보를 사용할 수 있는 기능을 제공할 사용자/팀을 하나 이상 지정할 수 있습니다.
시스템 관리자와 조직 관리자는 (해당 조직의 멤버인 사용자/팀 중에서) (동적 또는 수동으로) 인벤토리를 업데이트할 수 있는 사용자/팀을 하나 이상 지정할 수 있습니다. 관리자는 인벤토리에 임시 명령을 실행할 수도 있습니다.
31.2.2.5. 작업 템플릿 편집¶
시스템 관리자, 조직 관리자, 프로젝트 관리자는 자신에게 제공되는 관리 기능에 따라 프로젝트 내에서 해당 프로젝트에 대해 새 작업 템플릿을 생성하고 수정할 수 있습니다.
When editing a job template, administrators (automation controller, organization, and project) can select among the inventory and credentials in the organization for which they have usage capabilities or they may leave those fields blank so that they will be selected at runtime.
또한 (해당 프로젝트의 멤버인 사용자/팀 중) 해당 작업 템플릿을 실행할 수 있는 사용자/팀을 하나 이상 지정할 수 있습니다. 작업 템플릿에 지정된 인벤토리 또는 인증 정보에 대해 사용자/팀에 부여된 명시적 기능과 관계없이 실행 기능은 유효합니다.
31.2.2.6. 사용자 뷰¶
사용자는 다음을 수행할 수 있습니다.
멤버로 속한 모든 조직 또는 프로젝트 보기
자신에게만 해당하는 자체 인증 정보 오브젝트 생성
실행 기능이 부여된 모든 작업 템플릿 참조 및 실행
사용자에게 실행 기능이 제공된 작업 템플릿에서 인벤토리 또는 인증 정보를 지정하지 않는 경우, 런타임에 사용자에게 사용자가 소유하거나 사용 기능이 있는 조직의 인벤토리 및 인증 정보 중에서 선택하라는 메시지가 표시됩니다.
작업 템플릿 관리자인 사용자는 작업 템플릿을 변경할 수 있습니다. 그러나 작업 템플릿에 사용된 인벤토리, 프로젝트, 플레이북 또는 인증 정보를 변경하려면 사용자에게 현재 사용 중이거나 설정 중인 프로젝트 및 인벤토리에 대한 ‘사용’ 역할도 있어야 합니다.
31.2.3. 역할¶
이 문서의 앞부분에서 설명한 것처럼 인증 정보를 사용하거나 읽거나 쓸 수 있도록 부여하는 모든 액세스 권한이 이제 역할을 통해 처리되며, 역할은 리소스에 대해 정의됩니다.
31.2.3.1. 기본 제공 역할¶
The following table lists the RBAC system roles and a brief description of the how that role is defined with regard to privileges in automation controller.
시스템 역할 |
수행할 수 있는 작업 |
|---|---|
시스템 관리자 - 시스템 수준 싱글톤 |
시스템의 모든 측면 관리 |
시스템 감사자 - 시스템 수준 싱글톤 |
시스템의 모든 측면 보기 |
임시 역할 - 인벤토리 |
인벤토리에서 임시 명령 실행 |
관리자 역할 - 조직, 팀, 인벤토리, 프로젝트, 작업 템플릿 |
정의된 조직, 팀, 인벤토리, 프로젝트 또는 작업 템플릿의 모든 측면 관리 |
감사자 역할 - 모두 |
정의된 조직, 프로젝트, 인벤토리 또는 작업 템플릿의 모든 측면 보기 |
실행 역할 - 작업 템플릿 |
할당된 작업 템플릿 실행 |
멤버 역할 - 조직, 팀 |
Manages all of the settings associated with that Organization or Team |
읽기 역할 - 조직, 팀, 인벤토리, 프로젝트, 작업 템플릿 |
정의된 조직, 팀, 인벤토리, 프로젝트 또는 작업 템플릿의 모든 측면 보기 |
업데이트 역할 - 프로젝트 |
구성된 소스 제어 관리 시스템에서 프로젝트 업데이트 |
업데이트 역할 - 인벤토리 |
클라우드 소스 업데이트 시스템을 사용하여 인벤토리 업데이트 |
소유자 역할 - 인증 정보 |
이 인증 정보의 모든 측면 소유 및 관리 |
사용 역할 - 인증 정보, 인벤토리, 프로젝트 |
작업 템플릿의 인증 정보, 인벤토리 또는 프로젝트 사용 |
싱글톤 역할은 시스템 전체에 대한 권한을 부여하는 특수 역할입니다. |at|는 현재 두 가지 기본 제공 싱글톤 역할을 제공하고 있지만, 싱글톤 역할을 생성하거나 사용자 정의하는 기능은 지원하지 않습니다.
31.2.3.2. 일반적인 팀 역할 - 《사용자》¶
Automation controller support personnel typically works on ensuring that the controller is available and manages it a way to balance supportability and ease-of-use for users. Often, automation controller support will assign “Organization Owner/Admin” to users in order to allow them to create a new Organization and add members from their team the respective access needed. This minimizes supporting individuals and focuses more on maintaining uptime of the service and assisting users who are using automation controller.
Below are some common roles managed by the automation controller Organization:
시스템 역할
(조직의 경우)
|
일반 사용자
역할
|
설명
|
소유자
|
팀 리더 -
기술 리더
|
이 사용자는 조직의 다른 사용자가 액세스하는 권한을 제어할 수 있습니다.
프로젝트, 인벤토리, 작업 템플릿에 대한 특정 액세스 권한을 추가/제거하고 사용자에게 부여할 수 있습니다.
또한 이 사용자는 조직의 프로젝트, 템플릿, 인벤토리, 팀, 인증 정보에 걸친 모든 측면을
생성/제거/수정할 수 있습니다.
|
감사자
|
보안 엔지니어 -
프로젝트 관리자
|
이 계정은 읽기 전용 모드로 조직의 모든 측면을 볼 수 있습니다.
따라서 규정 준수를 확인하고 유지하는 사용자에게 유용할 수 있습니다.
또한 이 역할은 Ansible Tower의 작업 데이터를 관리하거나 일부 다른 데이터 수집기로
ships job data from automation controller to some other data collector.
|
멤버 -
팀
|
기타 모든 사용자
|
이러한 사용자는 기본적으로 조직 멤버이며, 조직의 어떤 측면에도
액세스할 수 없습니다. 이러한 사용자에게 액세스 권한을 부여하려면 각 조직 소유자가
각 팀에 이들 사용자를 추가하고, 조직의 프로젝트, 인벤토리, 작업 템플릿의 각 구성 요소에 대한
관리, 실행, 사용, 업데이트, 임시 권한을 부여해야 합니다.
|
멤버 -
팀 ‘소유자’
|
고급 사용자 -
주요 개발자
|
조직 소유자는 팀 인터페이스를 통해 프로젝트, 인벤토리, 작업 템플릿을 포함한 모든
조직 구성 요소를 담당하는 ‘관리자’를 제공할 수 있습니다. 이러한 사용자는
액세스 권한을 부여받은 각 구성 요소를 수정하고 활용할 수 있습니다.
|
멤버 -
팀 ‘실행’
|
개발자 -
엔지니어
|
가장 일반적인 역할로, 조직 멤버가 작업 템플릿을 실행하고 특정 구성 요소에 대한 권한을
읽을 수 있도록 허용합니다. 이 역할은 템플릿에 적용되는 권한에 해당합니다.
|
멤버 -
팀 ‘사용’
|
개발자 -
엔지니어
|
이 권한은 조직의 인증 정보, 인벤토리, 프로젝트에 적용됩니다.
이 권한은 사용자가 작업 템플릿 내의 각 구성 요소를 사용할 수 있도록 허용합니다.
|
멤버 -
팀 ‘업데이트’
|
개발자 -
엔지니어
|
이 권한은 프로젝트에 적용됩니다. 사용자가 프로젝트에서 SCM 업데이트를 실행할 수 있도록 허용합니다.
|
31.3. 역할의 기능: 편집 및 생성¶
automation controller 3.3에는 워크플로우와 같은 특정 리소스 유형과 관련된 조직의 ‘리소스 역할’ 기능이 새롭게 도입되었습니다. 이러한 역할의 멤버가 되면 일반적으로 두 가지 유형의 권한이 제공됩니다. 워크플로우의 경우 사용자에게 조직 《Default》에 대한 《워크플로우 관리자 역할》이 제공됩니다.
이 사용자는 조직 《Default》에 새 워크플로우를 생성할 수 있습니다.
사용자는 《Default》 조직의 모든 워크플로우를 편집할 수 있습니다.
한 가지 예외는 역할을 갖는 것이 생성 권한과 관련이 없는 작업 템플릿입니다(자세한 내용은 자체 섹션 참조).
31.3.1. 리소스 역할 및 조직 멤버 역할의 독립성¶
리소스별 조직 역할은 조직 역할인 관리자 및 멤버와 독립적입니다. 《Default》 조직에 대한 《워크플로우 관리자 역할》이 있다고 해서 사용자가 조직의 모든 사용자를 볼 수 있는 것은 아니지만, 《Default》 조직에서 《멤버》 역할이 있으면 볼 수 있습니다. 두 가지 유형의 역할은 서로 독립적으로 위임됩니다.
31.3.1.1. 작업 템플릿을 편집하는 데 필요한 권한¶
작업 실행에 영향을 미치지 않는 필드(민감하지 않은 필드)의 경우 사용자는 작업 템플릿 관리자 역할만으로도 필드를 편집할 수 있습니다. 그러나 작업 템플릿에서 작업 실행에 영향을 미치는 필드를 편집하려면 사용자에게 다음이 필요합니다.
작업 템플릿에 대한 관리자 역할
관련 프로젝트에 대한 사용 역할
관련 인벤토리에 대한 사용 역할
《조직 작업 템플릿 관리자》 역할이 도입되었지만 작업 템플릿에서 사용하는 프로젝트/인벤토리에 대한 사용 역할이 없는 경우 이 역할만으로는 조직 내 작업 템플릿을 편집하기에 충분하지 않습니다.
(조직 내) 전체 작업 템플릿 제어를 사용자 또는 팀에 위임하려면 팀 또는 사용자에게 세 가지 조직 수준 역할을 모두 부여해야 합니다.
작업 템플릿 관리자
프로젝트 관리자
인벤토리 관리자
그러면 사용자(또는 이러한 역할이 있는 팀의 멤버인 모든 사용자)에게 조직의 작업 템플릿을 수정할 수 있는 전체 액세스 권한이 부여됩니다. 작업 템플릿에서 다른 조직의 인벤토리나 프로젝트를 사용하는 경우 이러한 조직 역할의 사용자가 여전히 해당 작업 템플릿을 수정할 권한이 없을 수 있습니다. 권한을 명확하게 관리하기 위해 다른 조직의 프로젝트/인벤토리를 혼합하지 않는 것이 가장 좋습니다.
31.3.1.2. RBAC 권한¶
각 역할에는 콘텐츠 오브젝트가 있어야 합니다(예: 조직 관리자 역할에는 조직의 콘텐츠 오브젝트가 있음). 역할을 위임하려면 사용자 암호를 재설정할 수 있는 일부 예외를 제외하고 콘텐츠 오브젝트에 대한 관리자 권한이 필요합니다.
**상위**는 해당 조직입니다.
**허용**은 이 새 권한이 명시적으로 허용하는 항목입니다.
**범위**는 이 새 역할이 생성될 상위 리소스입니다. 예를 들면 ``Organization.project_create_role``입니다.
리소스 생성자에게 해당 리소스에 대한 관리자 역할을 부여해야 한다고 가정하고 있습니다. 리소스 생성이 리소스 관리를 의미하지는 않는 인스턴스가 있는 경우 명시적으로 호출됩니다.
다음은 각 관리자 유형과 연결된 규칙입니다.
프로젝트 관리자
허용: 모든 프로젝트의 생성, 읽기, 업데이트, 삭제
범위: 조직
사용자 인터페이스: 프로젝트 추가 화면 - 조직
인벤토리 관리자
상위: 조직 관리자
허용: 인벤토리 생성, 읽기, 업데이트, 삭제
범위: 조직
사용자 인터페이스: 인벤토리 추가 화면 - 조직
참고
사용 역할과 마찬가지로 사용자에게 프로젝트 관리자 및 인벤토리 관리자 역할을 부여하면 사용자가 조직의 작업 템플릿(워크플로우 아님)을 생성할 수 있습니다.
인증 정보 관리자
상위: 조직 관리자
허용: 공유 인증 정보의 생성, 읽기, 업데이트, 삭제
범위: 조직
사용자 인터페이스: 인증 정보 추가 화면 - 조직
알림 관리자
상위: 조직 관리자
허용: 알림 할당
범위: 조직
워크플로우 관리자
상위: 조직 관리자
허용: 워크플로우 생성
범위: 조직
조직 실행
상위: 조직 관리자
허용: JT 및 WFJT 실행
범위: 조직
다음은 조직과 해당 역할 그리고 각 역할이 액세스할 수 있는 리소스를 보여주는 샘플 시나리오입니다.
