OpenShift-보안

OpenShift 보안은 주로 보안 제약을 주로 처리하는 두 가지 구성 요소의 조합입니다.

보안 컨텍스트 제약 (SCC)
서비스 계정

보안 컨텍스트 제약 (SCC)

기본적으로 포드 제한에 사용됩니다. 즉, 수행 할 수있는 작업과 클러스터에서 액세스 할 수있는 모든 항목과 같이 포드에 대한 제한을 정의합니다.

OpenShift는 관리자가 사용, 수정 및 확장 할 수있는 사전 정의 된 SCC 세트를 제공합니다.

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

미리 정의 된 scc를 사용하려면 사용자 또는 그룹을 scc 그룹에 추가하기 만하면됩니다.

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

서비스 계정

서비스 계정은 기본적으로 마스터 또는 노드 머신에서 명령이나 요청이 실행될 때 호출되는 OpenShift 마스터 API에 대한 액세스를 제어하는 데 사용됩니다.

애플리케이션 또는 프로세스에 제한된 SCC에서 부여하지 않은 기능이 필요할 때마다 특정 서비스 계정을 만들고 해당 SCC에 계정을 추가해야합니다. 그러나 SCC가 요구 사항에 적합하지 않은 경우 가장 적합한 SCC를 사용하는 것보다 요구 사항에 맞는 새 SCC를 만드는 것이 좋습니다. 결국 배포 구성에 대해 설정하십시오.

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

컨테이너 보안

OpenShift에서 컨테이너 보안은 컨테이너 플랫폼의 보안 수준과 컨테이너가 실행되는 위치에 대한 개념을 기반으로합니다. 컨테이너 보안과 처리해야 할 사항에 대해 이야기 할 때 여러 가지가 떠 오릅니다.

Image Provenance − 생산 환경에서 실행되는 컨테이너의 출처를 정확하고 논란의 여지없이 식별하는 보안 라벨링 시스템이 마련되어 있습니다.

Security Scanning − 이미지 스캐너는 모든 이미지에서 알려진 취약점을 자동으로 확인합니다.

Auditing − 모든 컨테이너가 최신 컨테이너를 기반으로하고 호스트와 컨테이너가 모두 안전하게 구성되었는지 확인하기 위해 프로덕션 환경을 정기적으로 감사합니다.

Isolation and Least Privilege− 컨테이너는 효과적으로 작동하는 데 필요한 최소한의 리소스와 권한으로 실행됩니다. 그들은 호스트 또는 다른 컨테이너를 부당하게 방해 할 수 없습니다.

Runtime Threat Detection − 런타임에 컨테이너화 된 애플리케이션에 대한 활성 위협을 탐지하고 자동으로 대응하는 기능.

Access Controls − AppArmor 또는 SELinux와 같은 Linux 보안 모듈은 액세스 제어를 시행하는 데 사용됩니다.

컨테이너 보안을 보관하는 주요 방법은 거의 없습니다.

oAuth를 통한 액세스 제어
셀프 서비스 웹 콘솔을 통해
플랫폼 인증서 별

OAuth를 통한 액세스 제어

이 방법에서 API 제어 액세스에 대한 인증은 OpenShift 마스터 머신에 내장 된 OAuth 서버를 통해 인증을위한 보안 토큰을 확보하여 보관됩니다. 관리자는 OAuth 서버 구성의 구성을 수정할 수 있습니다.

OAuth 서버 구성에 대한 자세한 내용은이 자습서의 5 장을 참조하십시오.

셀프 서비스 웹 콘솔을 통해

이 웹 콘솔 보안 기능은 OpenShift 웹 콘솔에 내장되어 있습니다. 이 콘솔은 함께 작업하는 모든 팀이 인증없이 다른 환경에 액세스 할 수 없도록합니다. OpenShift의 다중 텔넷 마스터에는 다음과 같은 보안 기능이 있습니다.

TCL 레이어가 활성화 됨
인증을 위해 x.509 인증서 사용
마스터 시스템에서 etcd 구성을 보호합니다.

플랫폼 인증서 별

이 방법에서 각 호스트에 대한 인증서는 Ansible을 통해 설치 중에 구성됩니다. Rest API를 통해 HTTPS 통신 프로토콜을 사용하므로 다양한 구성 요소 및 개체에 대한 TCL 보안 연결이 필요합니다. 이들은 미리 정의 된 인증서이지만 액세스를 위해 마스터 클러스터에 사용자 지정 인증서를 설치할 수도 있습니다. 마스터의 초기 설정 중에 다음을 사용하여 기존 인증서를 재정 의하여 사용자 지정 인증서를 구성 할 수 있습니다.openshift_master_overwrite_named_certificates 매개 변수.

Example

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

사용자 지정 인증서를 생성하는 방법에 대한 자세한 내용은 다음 링크를 방문하십시오.

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

네트워크 보안

OpenShift에서는 SDN (소프트웨어 정의 네트워킹)이 통신에 사용됩니다. 네트워크 네임 스페이스는 클러스터의 각 포드에 사용되며, 각 포드는 자체 IP와 포트 범위를 가져와 네트워크 트래픽을 가져옵니다. 이 방법을 사용하면 다른 프로젝트의 pod와 통신 할 수없는 pod를 격리 할 수 있습니다.

프로젝트 분리

이것은 클러스터 관리자가 다음을 사용하여 수행 할 수 있습니다. oadm command CLI에서.

$ oadm pod-network isolate-projects <project name 1> <project name 2>

이는 위에 정의 된 프로젝트가 클러스터의 다른 프로젝트와 통신 할 수 없음을 의미합니다.

볼륨 보안

볼륨 보안은 OpenShift 클러스터에서 프로젝트의 PV 및 PVC를 보호하는 것을 의미합니다. OpenShift에서 볼륨에 대한 액세스를 제어하기위한 주로 4 개의 섹션이 있습니다.

보충 그룹
fsGroup
runAsUser
seLinuxOptions

보충 그룹-보충 그룹은 일반 Linux 그룹입니다. 프로세스가 시스템에서 실행되면 사용자 ID 및 그룹 ID로 실행됩니다. 이 그룹은 공유 스토리지에 대한 액세스를 제어하는 데 사용됩니다.

다음 명령을 사용하여 NFS 마운트를 확인하십시오.

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

다음 명령을 사용하여 마운트 서버에서 NFS 세부 정보를 확인합니다.

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/ 옵션 / NFS / 수출 UID에서 액세스 할 수454265 그리고 그룹 2325.

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup은 컨테이너 보충 그룹을 추가하는 데 사용되는 파일 시스템 그룹을 나타냅니다. 보조 그룹 ID는 공유 스토리지에 사용되며 fsGroup은 블록 스토리지에 사용됩니다.

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser는 통신에 사용자 ID를 사용합니다. 포드 정의에서 컨테이너 이미지를 정의하는 데 사용됩니다. 필요한 경우 모든 컨테이너에서 단일 ID 사용자를 사용할 수 있습니다.

컨테이너를 실행하는 동안 정의 된 ID는 내보내기의 소유자 ID와 일치합니다. 지정된 ID가 외부에 정의 된 경우 포드의 모든 컨테이너에 대해 전역이됩니다. 특정 포드로 정의 된 경우 단일 컨테이너에만 적용됩니다.

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265