1.3. OpenShift Container Platform은 어떻게 보호됩니까?


OpenShift Container Platform 및 Kubernetes API는 자격 증명을 제공하는 사용자를 인증한 다음 역할에 따라 권한을 부여합니다. 개발자와 관리자는 모두 주로 OAuth 토큰과 X.509 클라이언트 인증서 등 여러 가지 수단을 통해 인증할 수 있습니다. OAuth 토큰은 SHA-256을 사용한 RSA 서명 알고리즘인 PKCS#1 v1.5인 JSON Web Algorithm RS256 으로 서명됩니다.

개발자(시스템의 클라이언트)는 일반적으로 브라우저를 통해 oc 또는 웹 콘솔과 같은 클라이언트 프로그램에서 REST API 호출을 수행하고 대부분의 통신에 OAuth 전달자 토큰을 사용합니다. 인프라 구성 요소(노드와 같은)는 ID가 포함된 시스템에서 생성한 클라이언트 인증서를 사용합니다. 컨테이너에서 실행되는 인프라 구성 요소는 서비스 계정 과 연결된 토큰을 사용하여 API에 연결합니다.

권한 부여는 "Pod 생성" 또는 "list services"와 같은 작업을 정의하고 정책 문서의 역할에 그룹화하는 OpenShift Container Platform 정책 엔진에서 처리됩니다. 역할은 사용자 또는 그룹 식별자로 사용자 또는 그룹에 바인딩됩니다. 사용자 또는 서비스 계정이 작업을 시도하면 정책 엔진은 계속 허용하기 전에 사용자에게 할당된 하나 이상의 역할(예: 현재 프로젝트의 클러스터 관리자 또는 관리자)을 확인합니다.

클러스터에서 실행되는 모든 컨테이너는 서비스 계정과 연결되므로 시크릿 을 해당 서비스 계정에 연결하고 컨테이너에 자동으로 제공할 수도 있습니다. 이를 통해 인프라는 이미지, 빌드 및 배포 구성 요소를 가져오고 푸시하기 위한 시크릿을 관리할 수 있으며 애플리케이션 코드에서 이러한 시크릿을 쉽게 활용할 수 있습니다.

1.3.1. TLS 지원

REST API와의 모든 통신 채널은 물론 etcd 및 API 서버 등의 마스터 구성 요소 간 통신 채널은 TLS로 보호됩니다. TLS는 X.509 서버 인증서 및 공개 키 인프라를 사용하여 서버의 강력한 암호화, 데이터 무결성 및 인증을 제공합니다. 기본적으로 OpenShift Container Platform의 각 배포에 대해 새로운 내부 PKI가 생성됩니다. 내부 PKI는 2048비트 RSA 키와 SHA-256 서명을 사용합니다. 공용 호스트에 대한 사용자 지정 인증서 도 지원됩니다.

OpenShift Container Platform은 Golang의 crypto/tls 표준 라이브러리 구현을 사용하며 외부 암호화 및 TLS 라이브러리를 사용하지 않습니다. 또한 클라이언트는 GSSAPI 인증 및 OpenPGP 서명을 위한 외부 라이브러리에 의존합니다. GSSAPI는 일반적으로 MIT Kerberos 또는 Heimdal Kerberos에서 제공하며, 둘 다 OpenSSL의 libcrypto를 사용합니다. OpenPGP 서명 확인은 libgpgme 및 GnuPG에서 처리합니다.

안전하지 않은 버전의 SSL 2.0 및 SSL 3.0은 지원되지 않으며 사용할 수 없습니다. OpenShift Container Platform 서버 및 oc 클라이언트는 기본적으로 TLS 1.2만 제공합니다. TLS 1.0 및 TLS 1.1은 서버 구성에서 활성화할 수 있습니다. 서버와 클라이언트 모두 인증된 암호화 알고리즘과 완벽한 전달 보안을 갖춘 최신 암호화 제품군을 선호합니다. RC4, 3DES, MD5와 같이 더 이상 사용되지 않고 안전하지 않은 알고리즘이 있는 암호화 제품군이 비활성화됩니다. 일부 내부 클라이언트(예: LDAP 인증)는 TLS 1.0에서 1.2로 설정이 덜 제한되고 더 많은 암호 제품군이 활성화되어 있습니다.

표 1.1. 지원되는 TLS 버전
TLS 버전OpenShift Container Platform Serveroc 클라이언트기타 클라이언트

SSL 2.0

지원되지 않음

지원되지 않음

지원되지 않음

SSL 3.0

지원되지 않음

지원되지 않음

지원되지 않음

TLS 1.0

아니요 [1]

아니요 [1]

아마도 [2]

TLS 1.1

아니요 [1]

아니요 [1]

아마도 [2]

TLS 1.2

있음

있음

있음

TLS 1.3

N/A [3]

N/A [3]

N/A [3]

  1. 기본적으로 비활성화되지만 서버 구성에서 활성화할 수 있습니다.
  2. LDAP 클라이언트 등의 일부 내부 클라이언트.
  3. TLS 1.3은 아직 개발 중입니다.

OpenShift Container Platform 서버 및 oc 클라이언트에서 활성화된 암호화 제품군의 다음 목록은 기본으로 정렬됩니다.

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.