Openshift Compliance Operator를 알아보자

hojlee·2021년 12월 14일
ComplianceOpenSCAPOpenshiftRHOCPRed Hatoperator
0

시작하기 전에

많은 기업이 시스템의 보안 구성을 위해 CIS(Center for Internet Security) 프레임워크 및 기타 Best-Practice를 따라야 하는 정책을 가지고 있습니다. Red Hat Openshift Conatiner Platform(RHOCP) 사용 시, Operator Hub를 통해 Compliance Operator를 간단히 구성하고 이용할 수 있습니다. Openshift Compliance Operator는 NIST 인증 도구인 OpenSCAP을 사용하여 해당 프로젝트에서 제공하는 Openshift 클러스터와 각 Node의 OS(CoreOS)의 보안 정책을 검사할 수 있습니다.
이 글을 통해 Openshift Compliance Operator를 설치하고 사용하는 방법에 대해 다루려고 합니다.

Compliance Operator

Compliance Operator를 왜 사용해야 하죠?

플랫폼 보안을 위해서 무엇을 고려해야 할까요🤔

OpenShift 클러스터를 보호하려면 플랫폼(Openshift-Kubernetes)과 각 Node의 호스트 OS(RHCOS, RHEL) 관점을 모두 고려해야 합니다.
먼저 호스트 OS의 보안을 강화하는 방법은 기존의 RHEL의 보안을 강화하는 방식과 거의 동일합니다. 파일에 적절한 적합한 권한이 있는지 확인하고, 파일의 소유권이 적합하게 설정되어 있는지, 필요한 시스템의 서비스와 프로세스가 적절한 파라미터를 사용하여 시작되고 이상은 없는지 등이 이에 해당합니다.
플랫폼의 보안은 Openshift(Kubernetes)의 Master 구성파일을 포함하는 Control Plane의 구성요소가 적절한 파라미터로 구성되고 문제는 없는지, Audit Log는 활성화되어 있는지, ETCD의 피어구성은 제대로 되어있는지, RBAC 권한 관리에는 문제가 없는지 등을 확인해야 합니다.

보안 고려 항목은 직접 고민해야 하나요🤔

OpenShift는 OpenShift Security Guide Book에 설명되어 있는 것처럼 기본적으로 안전하며, 호스트 OS에서 컨테이너 오케스트레이션에 이르는 여러 보안 기능이 내장되어 있습니다. 추가 보안 측면을 위해 Compliance Operator는 Openshift 클러스터를 보호하거나 강화하는 데 필요한 것이 무엇인지 가이드를 제시하고 있습니다. CIS(Center for Internet Security) 벤치마크를 위한 Compliance Profile을 제공하고 있어, 모든 보안 고려사항을 직접 고민하지 않더라도 목적에 맞는 Profile을 선택한 후 보안 검사 및 검사결과에 따른 조치를 취할 수 있습니다. Compliance Operator를 설치했을때 기본적으로 생성되는 Compliance Profile은 NIST 800-53 Moderate(FedRAMP), Australian Cyber Security Center(ACSC) Essential Eight, CIS OpenShift Benchmark 등이 포함되어 있습니다. 특수한 보안요건의 경우, 기본적으로 제공되는 프로필 외에 자신의 프로필을 만들거나 조정할 수도 있습니다.

보안 검사는 어떻게 진행되는 건가요🤔

Compliance Operator는 아래와 같이 정의되어 있습니다.
Compliance Operator는 관리자가 Compliance 스캔을 실행하고, 발견된 문제에 대한 개선사항을 제공할 수 있는 OpenShift Operator입니다. 이 Operator는 내부적으로 OpenSCAP를 활용하여 스캔을 수행합니다.

즉, Compliance Operator가 호스트와 플랫폼을 확인하고 스캔할 프로필을 지정하여, Compliance의 차이가 나는 부분을 감지하고 이에 대한 요약 레포트를 생성합니다. 이를 통해 클러스터에서 정책을 위반하는 구성이 있는지 찾을 수 있습니다. 레포트에는 어떤 수정 사항이 적용되었는지 표시되기 때문에 권장 구성을 수동으로 적용할지, 단계별로 적용할지 또는 자동으로 적용할지 선택할 수 있습니다.

요약하면, 전체 프로세스는 위와 같이 진행됩니다.

  1. 스캔 프로필 선택
  2. 스캔 설정 지정 & 스캔 시작
  3. 보고서 생성

Compliance Operator 설치방법

Openshift Compliance Operator는 Openshift Web Console의 Operator Hub를 통해 간단하게 설치할 수 있습니다.

Openshift Administrator Web Console에서 Operator Hub를 선택합니다.
왼쪽 메뉴의 Operator-Operator Hub 선택

Operator Hub에서 Comliance Operator를 선택합니다.

설치 버튼을 클릭하면 Compliacne-Operator 구성을 위한 간단한 설정을 적용할 수 있고, Operator에서 제공하는 API를 확인할 수 있습니다.
기본값으로 설치해도 기능상 문제가 없으나 특정 Namespace에 배포하거나 Operator의 업데이트 정책을 변경하고 싶을 경우 추가 설정가능.

설치된 Compliance Operator는 아래와 같이 확인할 수 있습니다.
왼쪽 메뉴의 Operator-설치된 Operator 선택 후 Compliance Operator 상태 확인

Compliance Operator 구성요소

Compliance Operator는 아래와 같은 구조로 동작하고, 주요 CRD( CustomResourceDefinition) Object에 대한 간략한 설명은 다음과 같습니다.

ObjectDescription
ComplianceSuite클러스터에 적용할 ComplianceScan의 묶음을 나타냅니다. 스케줄링을 통해 여러개의 ComplianceScan을 반복적으로 수행할 수 있습니다.
ComplianceScan특정 조건으로 수행되는 단일 Scan을 나타냅니다. 특정 Node를 지정하여 수행할 수 있습니다.
ScanSettingScan의 세부 내용을 나타냅니다. Scan결과물이 저장될 PV, Scan을 수행할 스케줄링 및 역할을 정의할 수 있습니다.
ScanSettingBinding수행할 내용인 Profile과 ScanSetting 연결하는 Object입니다. ScanSettingBinding을 생성하면 ComplianceScan이 생성됩니다.
Profile보안 검사를 수행하는 상세 내용 입니다. NIST, ACSC의 Profile 등이 포함되어 있습니다.
ComplianceCheckResultProfile에 정의된 여러개의 보안검사 항목 중, 단일 테스트의 결과를 나타냅니다. 한번의 ComplianceScan은 다수의(최소 1개) ComplianceCheckResult를 생성합니다.
ComplianceRemediationComplianceCheckResult로 발견된 문제를 개선하기위한 방법을 나타냅니다.

이 외에도 ProfileBundle, Rule, TailoredProflie, Variable등의 CRD Object들이 있음

아래에서 설명할 Compliance Operator의 CRD(CustomResourceDefinition)들은 공식 GitHub에서 보다 자세히 확인할 수 있으며, Object 생성을 위해 참고하기 좋습니다.

Compliance Operator GitHub
Compliance Operator GitHub CRD

ComplianceSuite

ComplianceSuite는 ComplianceScan의 묶음으로 구성되어 있으며, Scan에 대한 보다 상세한 설정을 할 수 있습니다. 일반적으로는 ScanSetting과 ScanSettingBinding의 정의를 통해 ComplianceScan을 수행하지만, 여러개의 ComplianceScan을 수행하거나 debug 모드를 통해 테스트를 진행해야 할 경우 ComplianceSuite가 필요합니다. 아래는 platform과 worker의 ComplianceScan을 포함하고, worker는 특정노드(worker)에서만 debug 모드로 수행하는 ComplianceSuite의 예시입니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceSuite
metadata:
  name: example-compliancesuite
spec:
  autoApplyRemediations: false
  schedule: "0 1 * * *"
  scans:
    - name: workers-scan
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-rhcos4-ds.xml
      contentImage: quay.io/complianceascode/ocp4:latest
      debug: true
      nodeSelector:
        node-role.kubernetes.io/worker: ""
    - name: platform-scan
      scanType: Platform
      profile: xccdf_org.ssgproject.content_profile_moderate
      content: ssg-ocp4-ds.xml
      contentImage: quay.io/complianceascode/ocp4:latest
  • 디버그 모드 제공 : 'debug: true' 설정을 통한 디버그모드를 제공합니다. 디버그 모드를 사용할 경우, 자세한 정보를 출력해서 정보의 양이 증가하게 됩니다. 따라서 검사할 단일 규칙만 지정함으로서 OpenSCAP 스캐너 상세도를 증가시키는 속성과 함께 디버깅에 유용하게 사용할 수 있습니다. 테스트를 하나의 규칙으로 제한하면 디버그 정보의 양을 줄이는 데 도움이 됩니다.
  • 사용자 정의 nodeSelector 제공 : nodeSelector를 사용할 수 있으며, 만약 remediation을 사용할 경우 nodeSelector가 풀과 일치해야 합니다.
  • 프로필의 구문을 분석할 필요가 없는(구문분석을 위한 오버헤드를 제거할 수 있음) 테스트 또는 개발용으로 사용하기 좋습니다.

ScanSetting

ScanSetting은 주로 schedule과 role(node-role.kubernetes.io Label)을 정의하여 ComplianceScan의 수행주기와 대상(Node Level)을 지정합니다. 아래의 yaml은 오전 1시에 시작되고 Master와 및 Worker Node에서 실행하며, 2Gi의 Persistent Storage에 Scan결과를 10개까지 저장하는 ScanSetting의 예시입니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSetting
metadata:
  name: my-companys-constraints
# Suite-specific settings
autoApplyRemediations: false
schedule: "0 1 * * *"
# Scan-specific settings
rawResultStorage:
  size: "2Gi"
  rotation: 10
# For each role, a separate scan will be created pointing
# to a node-role specified in roles
roles:
  - worker
  - master

autoApplyRemediations 값은 스캔에 대한 수정 사항이 자동으로 적용되고 아래 예에서 비활성화되는지 여부를 지정합니다. 모든 개선 항목을 자동으로 적용하려면 autoApplyRemediation을 false 대신 true로 설정해야 합니다.

Profile

ComplianceScan 실제 수행 항목을 정의한 Object입니다. Profile에는 Profile을 구성하는 메타데이터들과 실제 수행 항목인 Rule로 구성되어있으며, Compliance Operator 구성 시 최신 정책을 반영한 Profile이 기본으로 생성됩니다.아래는 RHOCP 4의 Host OS인 CoreOS를 점검하는 Profile의 일부입니다. Profile을 구성하는 다수의 Rule이 추가되어 있는 것을 볼 수 있습니다.

apiVersion: compliance.openshift.io/v1alpha1
description: |-
  This compliance profile reflects the core set of Moderate-Impact Baseline
  configuration settings for deployment of Red Hat Enterprise
  Linux CoreOS into U.S. Defense, Intelligence, and Civilian agencies.
<...>
id: xccdf_org.ssgproject.content_profile_moderate
kind: Profile
metadata:
  annotations:
    compliance.openshift.io/product: redhat_enterprise_linux_coreos_4
    compliance.openshift.io/product-type: Node
  labels:
    compliance.openshift.io/profile-bundle: rhcos4
<...>
  name: rhcos4-moderate
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ProfileBundle
    name: rhcos4
<...>
rules:
- rhcos4-account-disable-post-pw-expiration
- rhcos4-accounts-no-uid-except-zero
- rhcos4-audit-rules-dac-modification-chmod
<...>
title: NIST 800-53 Moderate-Impact Baseline for Red Hat Enterprise Linux CoreOS

ScanSettingBinding

ScanSettingBinding은 사용할 프로필과 스캔 상세를 정의한 ScanSetting을 Binding하는 정보를 담고 있습니다. 이 Object를 통해 Scanner Pod를 생성하는 ComplianceSuite 및 ComplianceScan Object를 생성합니다. 아래는 ScanSetting 예시에서 생성한 my-companys-constraints ScanSetting과 rhcos4-moderate Profile을 Binding하는 예시입니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ScanSettingBinding
metadata:
  name: nist-moderate
profiles:
  - name: rhcos4-moderate
    kind: Profile
    apiGroup: compliance.openshift.io/v1alpha1
settingsRef:
  name: my-companys-constraints
  kind: ScanSetting
  apiGroup: compliance.openshift.io/v1alpha1

ComplianceScan

ComplianceScan은 단일 Scan을 나타냅니다. 일반적으로 ScanSetting과 ScanSettingBinding의 정의를 통해 ComplianceScan을 수행하지만, 스케줄링이 필요없고 단일 Scan을 위해 직접 생성해야 할 경우 사용합니다. 아래의 예시처럼 단일 proflie에 정의된 Scan을 수행하며 ComplianceScan을 생성할 경우(create or apply), Scan을 수행하는 pod가 기동됩니다. 

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: example-compliancescan
spec:
  profile: xccdf_org.ssgproject.content_profile_moderate
  content: ssg-rhcos4-ds.xml

ComplianceScan을 완료하면 기동했던 Pod는 종료되며, 아래와 같은 수행결과를 확인할 수 있습니다. 아래는 ComplianceScan 결과, 보안 개선사항이 필요한 예시입니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceScan
metadata:
  name: worker-scan
spec:
  scanType: Node
  profile: xccdf_org.ssgproject.content_profile_moderate
  content: ssg-ocp4-ds.xml
  contentImage: quay.io/complianceascode/ocp4:latest
  rule: "xccdf_org.ssgproject.content_rule_no_netrc_files"
  nodeSelector:
    node-role.kubernetes.io/worker: ""
status:
  phase: DONE
  result: NON-COMPLIANT

Scan이 완료될 경우, 간단한 결과내용은 Compliance Operator가 구성되어있는 Namespace에 Configmap으로 생성되고 Persistent Volume에는 RAW data가 저장되고 이를 활용하여 report를 생성할 수 있습니다. Scan 항목(Rule)의 결과 마다 ComplianceCheckResult Object가 생성되어, 각 항목의 세부정보를 API로 호출할 수 있습니다. 용도에 따라 간단한 결과 확인(Configmap), 상세한 내용 확인(RAW data), API로 세부 결과 호출(ComplianceCheckResult)을 이용할 수 있습니다.

ComplianceCheckResult

ComplianceCheckResult는 Profile에 정의된 Rule에 따라 보안 점검 결과를 나타냅니다. Scan 시, Profile에 정의된 각각의 Rule의 수행결과마다 ComplianceCheckResult Object가 생성됩니다. 아래는 root 사용자로 SSH 로그인을 비활성화하는 Rule에 대해 점검한 결과 예시입니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceCheckResult
metadata:
  labels:
    compliance.openshift.io/check-severity: medium
    compliance.openshift.io/check-status: FAIL
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
  name: workers-scan-no-direct-root-logins
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceScan
    name: workers-scan
description: |-
  Direct root Logins Not Allowed
  Disabling direct root logins ensures proper accountability and multifactor
  authentication to privileged accounts. Users will first login, then escalate
  to privileged (root) access via su / sudo. This is required for FISMA Low
  and FISMA Moderate systems.
id: xccdf_org.ssgproject.content_rule_no_direct_root_logins
severity: medium
status: FAIL

Compliance Scan 실행 후, 아래와 같이 다수의 ComplianceCheckResult Object가 생성된 것을 확인할 수 있습니다.

ComplianceRemediation

ComplianceRemediation는 Rule에 대한 개선사항을 적용하는 방법을 나타냅니다.

apiVersion: compliance.openshift.io/v1alpha1
kind: ComplianceRemediation
metadata:
  labels:
    compliance.openshift.io/suite: example-compliancesuite
    compliance.openshift.io/scan-name: workers-scan
    machineconfiguration.openshift.io/role: worker
  name: workers-scan-disable-users-coredumps
  namespace: openshift-compliance
  ownerReferences:
  - apiVersion: compliance.openshift.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: ComplianceCheckResult
    name: workers-scan-disable-users-coredumps
    uid: <UID>
spec:
  apply: false
  object:
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    spec:
      config:
        ignition:
          version: 2.2.0
        storage:
          files:
          - contents:
              source: data:,%2A%20%20%20%20%20hard%20%20%20core%20%20%20%200
            filesystem: root
            mode: 420
            path: /etc/security/limits.d/75-disable_users_coredumps.conf

위의 예시에서 apply 값은 수정 적용 여부를 나타내며, object의 내용은 수정하는 내용을 나타냅니다. Scan내용을 설정할 때, AutoRemediation을 true로 설정하면 이 Object를 true로 설정하여 개선사항을 적용합니다.

Compliance Scan 실행 후, 아래와 같이 다수의 ComplianceRemediation Object가 생성된 것을 확인할 수 있습니다.

그럼 Compliance Scan 실행을 위해서는 어떻게 해야하나요🤔

앞서 설명했던 ComplianceSuite 또는 ScanSetting, ScanSettingBinding Object를 생성하는 방법으로 Commpliance Scan을 진행할 수 있습니다. RHOCP는 WebConsole에서 GUI환경으로 위의 Object를 생성, 조회, 수정, 삭제할 수 있습니다. 필수 파라미터를 표시해주고 있기 때문에 사용자 관점에서 편하게 이용할 수 있고 그 외에 추가적인 파라미터 또는 스키마도 쉽게 입력할 수 있습니다.

WebConsole에서 yaml 형식으로도 Object를 관리할 수 있습니다. 물론 CLI 환경에서 Object를 관리할 수 있으며, 이렇게 생성한 Object들 모두 WebConsle에서 확인할 수 있습니다.

Compliance Scan 결과는 어떻게 확인하나요🤔

아쉽게도 아직은 RHOCP WebConsole에서는 Scan의 최종 결과 Report를 제공하는 기능은 없습니다. 그 이유는 OpenSCAP 출력 결과가 ARF(Assessment Result Format)라는 거대한 XML 파일로 구성되어 있고 검사, 프로필 및 기타 정보에 대한 모든 세부 정보가 포함되어 있기 때문입니다. 이 RAW data는 ScanSetting에 정의한 Persistent Volume에 저장되며, oc cp 명령어로 RAW data를 복사하고 oscap 명령어로 RAW data를 html형식의 report 파일로 출력할 수 있습니다.

RAW data를 복사해 오는 방법은 여러가지가 있으나, 아래는 Compliance Operator 공식 GitHub에 가이드 되어있는 임시 pod를 기동하여 RAW data를 추출하는 방법입니다.

  1. RAW data PVC mount하는 임시 Pod를 생성합니다.
apiVersion: "v1"
kind: Pod
metadata:
  name: pv-extract
spec:
  containers:
    - name: pv-extract-pod
      image: registry.access.redhat.com/ubi8/ubi
      command: ["sleep", "3000"]
      volumeMounts:
        - mountPath: "/workers-scan-results"
          name: workers-scan-vol
  volumes:
    - name: workers-scan-vol
      # ComplianceScan으로 RAW data가 저장되는 PVC 설정
      persistentVolumeClaim:
        claimName: <pvc-name>
  1. 임시로 생성한 Pod에서 RAW data를 복사합니다. RAW data의 확장자는 bzip2 입니다.
$ oc cp pv-extract:/workers-scan-results .
  1. 복사한 RAW data를 html report로 변환합니다. 
# oscap 명령어를 사용하기 위해서는 oscap-scanner 패키지를 설치해야 합니다.
# yum install -y oscap-scanner
$ oscap xccdf generate report example.xml.bzip2 > ./Compliance_report.html

마치며

Openshift Compliance Operator는 CIS 벤치마크나 NIST등의 보안 표준을 준수할 수 있도록 도와주는 편리한 도구입니다. 이들이 제공하는 보안 정책을 준수하는 것은 중요하지만, 이를 준수하는데 목적을 두는 것이 아닌 표준을 기반으로 한 사용자의 정책을 만들어 나가는 것이 더 중요하다고 생각합니다.
이 글이 Openshift나 Kubernetes를 사용하는 분들에게 노하우를 쌓아 정책을 만들어갈 수 있는 계단이 되길 바라며, 추가적인 의견은 댓글로 작성해주시면 답변드리도록 하겠습니다.

참고한 문서들

profile
hojlee
홎리몰리 과카몰리
다음 포스트

Kustomize로 K8S 리소스 관리하기

0개의 댓글