1장. 보안 모범 사례
보다 유연한 개발 환경을 구축하는 데 도움이 될 수 있는 Red Hat OpenShift Dev Spaces의 주요 보안 관행에 대한 개요를 살펴보십시오.
Red Hat OpenShift Dev Spaces는 플랫폼을 제공하는 OpenShift 상단에서 실행되며 그 위에 작동하는 제품의 기반을 제공합니다. OpenShift 문서는 보안 강화의 진입점입니다.
OpenShift에서 프로젝트 격리
OpenShift에서 프로젝트 격리는 Kubernetes의 네임스페이스 격리와 유사하지만 프로젝트의 개념을 통해 달성됩니다. OpenShift의 프로젝트는 클러스터 내의 다양한 애플리케이션, 팀 또는 워크로드 간에 격리 및 협업을 제공하는 최상위 조직 단위입니다.
기본적으로 OpenShift Dev Spaces는 각 사용자에 대해 고유한 < username>-devspaces
프로젝트를 프로비저닝합니다. 또는 클러스터 관리자는 OpenShift 수준에서 프로젝트 자체 프로비저닝을 비활성화하고 CheCluster 사용자 정의 리소스에서 자동 네임스페이스 프로비저닝을 끌 수 있습니다.
devEnvironments: defaultNamespace: autoProvision: false
devEnvironments:
defaultNamespace:
autoProvision: false
이 설정을 사용하면 클러스터 관리자가 각 사용자에 대한 프로비저닝을 제어하고 리소스 제한 및 할당량을 포함하여 다양한 설정을 명시적으로 구성할 수 있는 OpenShift Dev Space에 대한 선별된 액세스 권한을 얻을 수 있습니다. 4.2.2절. “사전 프로비저닝 프로젝트” 에서 프로젝트 프로비저닝에 대해 자세히 알아보십시오.
RBAC(역할 기반 액세스 제어)
기본적으로 OpenShift Dev Spaces Operator는 다음 ClusterRoles를 생성합니다.
-
<namespace>-cheworkspaces-clusterrole
-
<namespace>-cheworkspaces-devworkspace-clusterrole
& lt;namespace
> 접두사는 Red Hat OpenShift Dev Spaces CheCluster CR이 있는 프로젝트 이름에 해당합니다.
사용자가 Red Hat OpenShift Dev Spaces에 처음 액세스하면 < username>-devspaces
프로젝트에서 해당 RoleBinding이 생성됩니다.
네임스페이스에 사용할 수 있는 권한을 사용자에게 부여할 수 있는 모든 리소스 및 작업은 아래에 나열되어 있습니다.
Resources | 작업 |
---|---|
pods | "get", "list", "watch", "create", "delete", "update", "patch" |
pods/exec | "get", "create" |
pods/log | "get", "list", "watch" |
pods/portforward | "get", "list", "create" |
configmaps | "get", "list", "create", "update", "patch", "delete" |
이벤트 | "list", "watch" |
secrets | "get", "list", "create", "update", "patch", "delete" |
services | "get", "list", "create", "delete", "update", "patch" |
routes | "get", "list", "create", "delete" |
persistentvolumeclaims | "get", "list", "watch", "create", "delete", "update", "patch" |
앱/배포 | "get", "list", "watch", "create", "patch", "delete" |
apps/replicasets | "get", "list", "patch", "delete" |
네임스페이스 | "get", "list" |
projects | "get" |
DevWorkspace | "get", "create", "delete", "list", "update", "patch", "watch" |
devworkspacetemplates | "get", "create", "delete", "list", "update", "patch", "watch" |
각 사용자에게는 네임스페이스에만 권한이 부여되며 다른 사용자의 리소스에는 액세스할 수 없습니다. 클러스터 관리자는 사용자에게 추가 권한을 추가할 수 있습니다. 기본적으로 부여된 권한은 제거해서는 안 됩니다.
Red Hat OpenShift Dev Spaces 사용자의 클러스터 역할을 구성하려면 제품 설명서 를 참조하십시오.
역할 기반 액세스 제어에 대한 자세한 내용은 OpenShift 설명서에서 확인할 수 있습니다.
dev 환경 격리
개발 환경의 격리는 OpenShift 프로젝트를 사용하여 구현됩니다. 모든 개발자에게는 다음 오브젝트가 생성되고 관리되는 프로젝트가 있습니다.
- IDE 서버를 포함한 CDE(Cloud Development Environment) 포드.
- Git 토큰, SSH 키 및 Kubernetes 토큰과 같은 개발자 인증 정보가 포함된 시크릿입니다.
- Git 이름 및 이메일과 같은 개발자별 구성이 있는 ConfigMap입니다.
- CDE Pod가 중지된 경우에도 소스 코드와 같은 데이터를 보관하는 볼륨.
네임스페이스의 리소스에 대한 액세스는 해당 리소스를 소유하는 개발자로 제한해야 합니다. 다른 개발자에게 읽기 액세스 권한을 부여하는 것은 개발자 자격 증명을 공유하는 것과 동일하므로 피해야 합니다.
권한 강화
현재 추세는 대규모 단연적 OpenShift 클러스터 대신 여러 " 목적의 적용" 클러스터로 인프라를 분할하는 것입니다. 그러나 관리자는 여전히 세분화된 액세스를 제공하고 특정 사용자에게 특정 기능의 가용성을 제한해야 할 수 있습니다.
OpenShift 클러스터는 특정 사용 사례 또는 워크로드의 요구 사항과 목표를 충족하도록 특별히 설계 및 구성된 클러스터를 나타냅니다. 이는 관리할 워크로드의 특성을 기반으로 성능, 리소스 사용률 및 기타 요인을 최적화하도록 조정됩니다. Red Hat OpenShift Dev Spaces의 경우 이러한 유형의 클러스터가 프로비저닝된 것이 좋습니다.
이를 위해 다양한 그룹 및 사용자에 대한 세분화된 액세스를 설정하는 데 사용할 수 있는 선택적 속성을 CheCluster 사용자 정의 리소스에서 사용할 수 있습니다.
-
허용 사용자
-
allowGroups
-
DenyUsers
-
denyGroups
다음은 액세스 구성의 예입니다.
networking: auth: advancedAuthorization: allowUsers: - user-a - user-b denyUsers: - user-c allowGroups: - openshift-group-a - openshift-group-b denyGroups: - openshift-group-c
networking:
auth:
advancedAuthorization:
allowUsers:
- user-a
- user-b
denyUsers:
- user-c
allowGroups:
- openshift-group-a
- openshift-group-b
denyGroups:
- openshift-group-c
denyUsers
및 denyGroup
카테고리의 사용자는 Red Hat OpenShift Dev Spaces를 사용할 수 없으며 사용자 대시보드에 액세스하려고 할 때 경고가 표시됩니다.
인증
인증된 OpenShift 사용자만 Red Hat OpenShift Dev Spaces에 액세스할 수 있습니다. 게이트웨이 Pod는 RBAC(역할 기반 액세스 제어) 하위 시스템을 사용하여 개발자가 CDE(Cloud Development Environment)에 액세스할 수 있는지 여부를 결정합니다.
CDE Gateway 컨테이너는 개발자의 Kubernetes 역할을 확인합니다. 해당 역할이 CDE 포드에 액세스할 수 있는 경우 개발 환경에 대한 연결이 허용됩니다. 기본적으로 네임스페이스의 소유자만 CDE Pod에 액세스할 수 있습니다.
네임스페이스의 리소스에 대한 액세스는 해당 리소스를 소유하는 개발자로 제한해야 합니다. 다른 개발자에게 읽기
액세스 권한을 부여하는 것은 개발자 자격 증명을 공유하는 것과 동일하므로 피해야 합니다.
보안 컨텍스트 및 보안 컨텍스트 제약 조건
Red Hat OpenShift Dev Spaces는 CDE Pod 컨테이너 보안 컨텍스트 사양에 SETGID
및 SETUID
기능을 추가합니다.
"spec": { "containers": [ "securityContext": { "allowPrivilegeEscalation": true, "capabilities": { "add": ["SETGID", "SETUID"], "drop": ["ALL","KILL","MKNOD"] }, "readOnlyRootFilesystem": false, "runAsNonRoot": true, "runAsUser": 1001110000 } ] }
"spec": {
"containers": [
"securityContext": {
"allowPrivilegeEscalation": true,
"capabilities": {
"add": ["SETGID", "SETUID"],
"drop": ["ALL","KILL","MKNOD"]
},
"readOnlyRootFilesystem": false,
"runAsNonRoot": true,
"runAsUser": 1001110000
}
]
}
이를 통해 사용자가 CDE 내에서 컨테이너 이미지를 빌드할 수 있습니다.
기본적으로 Red Hat OpenShift Dev Spaces는 이러한 기능으로 Pod를 시작할 수 있는 사용자에게 특정 SCC( SecurityContextConstraint
)를 할당합니다. 이 SCC는 기본 restricted
SCC에 비해 사용자에게 더 많은 기능을 부여하지만 anyuid
SCC에 비해 더 적은 기능을 제공합니다. 이 기본 SCC는 OpenShift Dev Spaces 네임스페이스에서 미리 생성되었으며 container-build
라는 이름으로 지정됩니다.
CheCluster 사용자 정의 리소스에서 다음 속성을 설정하면 추가 기능 및 SCC를 사용자에게 할당할 수 없습니다.
spec: devEnvironments: disableContainerBuildCapabilities: true
spec:
devEnvironments:
disableContainerBuildCapabilities: true
리소스 할당량 및 제한 범위
리소스 할당량 및 제한 범위는 클러스터 내에서 잘못된 행위자 및 리소스 오용을 방지하는 데 사용할 수 있는 Kubernetes 기능입니다. 특히 Pod 및 컨테이너에 대한 리소스 사용 제약 조건을 설정할 수 있습니다. 리소스 할당량 및 제한 범위를 결합하여 잘못된 행위자가 과도한 리소스를 사용하지 못하도록 프로젝트별 정책을 시행할 수 있습니다.
이러한 메커니즘은 OpenShift 클러스터 내에서 리소스 관리, 안정성 및 공정성을 개선하는 데 기여합니다. 리소스 할당량 및 제한 범위에 대한 자세한 내용은 OpenShift 설명서에서 확인할 수 있습니다.
연결이 끊긴 환경
Air-gapped OpenShift 연결이 끊긴 클러스터는 인터넷 또는 외부 네트워크와 분리된 OpenShift 클러스터를 나타냅니다. 이러한 격리는 잠재적인 데이터 위협으로부터 민감하거나 중요한 시스템을 보호하는 보안상의 이유로 발생하는 경우가 많습니다. Air-gapped 환경에서 클러스터는 외부 리포지토리 또는 레지스트리에 액세스하여 컨테이너 이미지, 업데이트 또는 종속 항목을 다운로드할 수 없습니다.
Red Hat OpenShift Dev Spaces가 지원되며 제한된 환경에 설치할 수 있습니다. 설치 지침은 공식 문서에서 확인할 수 있습니다.
확장 관리
기본적으로 Red Hat OpenShift Dev Spaces에는 Microsoft Visual Studio Code - Open Source 편집기에 대한 제한된 확장 세트가 포함된 임베디드 Open VSX 레지스트리가 포함되어 있습니다. 또는 클러스터 관리자는 수천 개의 확장 기능이 포함된 https://open-vsx.org 와 같이 사용자 정의 리소스에 다른 플러그인 레지스트리를 지정할 수 있습니다. 또한 사용자 지정 Open VSX 레지스트리를 빌드할 수도 있습니다. IDE 확장 관리에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다.
추가 확장을 설치하면 잠재적인 위험이 발생할 수 있습니다. 이러한 위험을 최소화하려면 신뢰할 수 있는 소스의 확장만 설치하고 정기적으로 업데이트해야 합니다.
보안
사용자의 네임스페이스에 Kubernetes 시크릿으로 중요한 데이터를 기밀로 유지합니다(예:PAT(개인 액세스 토큰) 및 SSH 키).
Git 리포지토리
익숙한 Git 리포지토리와 신뢰할 수 있는 Git 리포지토리 내에서 작업하는 것이 중요합니다. 새 종속성을 리포지토리에 통합하기 전에 해당 종속성이 잘 유지 관리되고 정기적으로 업데이트되어 해당 코드에서 식별된 보안 취약점을 해결합니다.