클라우드 네이티브 인증서 - 쿠버네티스를 위한 사실상의 표준

Couchbase는 TLS를 사용하여 네트워크 전반의 통신을 안전하게 보호함으로써 악의적인 제3자가 클라이언트 요청, 클러스터 간 요청(노드 간 암호화), 클러스터 내 요청(데이터센터 간 복제 - XDCR) 등의 요청을 도청하거나 변조하는 것을 방지합니다. 최신 릴리즈의 클라우드 네이티브 CAO(자율 운영자) 2.3은 사실상의 kubernetes.io/tls 인증서 및 연결된 키를 저장하기 위한 비밀 유형입니다.

TLS란 무엇인가요?

TLS(전송 계층 보안)는 네트워크를 통해 두 당사자 간의 통신을 보호하는 가장 일반적인 표준입니다. 인증, 암호화 및 무결성을 다룹니다. 가장 일반적인 용도는 HTTP 연결을 보호하는 것입니다. HTTPS 웹사이트를 방문할 때 한 번쯤 접해 보셨을 것입니다. 그리고 S 는 보안을 의미합니다! 일부 웹 브라우저의 주소 표시줄에 작은 자물쇠가 표시되어 있습니다.

웹사이트의 인증서를 보면 발급자, 유효 시작일 및 종료일과 같은 필드를 볼 수 있습니다. 간단히 말해서 발급자를 인증 기관(CA)이라고 합니다.

CA는 디지털 인증서를 발급하는 역할을 하는 신뢰할 수 있는 조직입니다. 컴퓨터 운영 체제에는 이미 설치된 CA 목록이 함께 제공됩니다. 그러나 이전 CA가 오래되어 업데이트가 필요하거나 자체 서명을 하고 싶어서 신뢰할 수 있는 새 CA를 추가할 수도 있습니다.

인증서 체인

CA를 신뢰하면 CA가 서명한 모든 인증서를 신뢰하게 됩니다. 현실적으로 CA를 그런 식으로 직접 라인에 배치하는 것은 너무 위험하기 때문에 CA가 중간 인증서에 서명하고 중간 인증서에 별도의 보안 도메인을 위임하는 것이 더 일반적입니다. 이 중간 인증서는 서명된 인증서를 만들 수도 있습니다. 이러한 최종 인증서는 서버에서 HTTPS 연결을 위해 브라우저에 제시하는 데 사용되는 경향이 있습니다. 

이러한 연속적인 서명으로 인해 인증서 체인. 브라우저는 인증서를 수신하고 CA에 도달할 때까지 체인을 올라갑니다. CA가 신뢰할 수 있는 CA 목록에 있으면 핸드셰이크가 계속되고 보안 연결이 이루어집니다. CA가 신뢰 저장소에 나타나지 않는다고 가정해 보겠습니다. 이 경우 브라우저에 다음과 유사한 오류가 표시됩니다.잘못된 인증 기관“. 

서버 인증서의 유효성을 확인하기 위해 인증서에서 사용할 수 있는 CA의 공개 키를 사용하여 인증서의 서명을 해독하고 유효성을 검사할 수 있습니다. 이 프로세스에 성공하면 악의적인 제3자가 아닌 서버가 실제로 인증서에 서명했음을 증명합니다.

하지만 이는 개인 키를 가진 사람은 누구나 원래 CA로 가장할 수 있다는 것을 의미하므로 중간 인증서를 사용하는 경향이 있습니다. 손상된 CA에 의해 발급된 모든 인증서가 무효화되는 것이 아니라 체인의 일부만 무효화됩니다. 

서명된 인증서를 신청하기 위해 최종 사용자는 개인 키와 인증서 서명 요청(CSR)을 만듭니다. CSR에는 최종 서명된 인증서에 포함된 개인 키의 보완 공개 키가 포함되어 있습니다. 동일한 논리에 따라 이 개인 키는 정보가 디지털 서명되고 인증서의 공개 키를 사용하여 검증할 수 있으므로 서버가 실제로 소유한 인증서를 사용하고 있음을 증명합니다.

TLS, Kubernetes 및 Couchbase 클라우드 네이티브 CAO

쿠버네티스는 이러한 인증서와 개인 키를 저장하기 위한 표준을 제공한다. kubernetes.io/tls 사양. 표준을 확립함으로써 모든 시스템이 일관된 형식으로 TLS 인증서와 키를 생성하고 사용하게 되어 상호 운용성이 향상됩니다. 최신 CAO 2.3 릴리스에서는 이 사양을 준수하는 비밀을 사용하는 것이 좋습니다.

이전에는 CAO 2.1에서 TLS 비밀은 다음과 같이 제공되었습니다. pkey.key 그리고 chain.pem 필드에서 하드코딩된 경로의 아티팩트로서 Couchbase 서버에서 발생합니다:

이 형식의 단점은 타사 인증서 관리 시스템과의 상호 운용성이 그다지 좋지 않다는 것입니다.

그런 다음 CAO 2.2는 다음을 지원하는 버전으로 출시되었습니다. 인증 관리자. 지원은 파일 이름을 변경하고 키를 다시 작성하는 번역 레이어를 생성하여 이루어졌습니다. PKCS#8 형식을 필요한 경우 필수 PKCS#1 형식으로 변경하여 Couchbase Server에서 제공하는 TLS 지원을 확장할 수 있습니다.

TLS의 비밀 제공처 인증 관리자 는 네이티브의 약간 확장된 kubernetes.io/tls 사양.

이 확장 사양은 추가 ca.crt 필드에 저장된 각 TLS 인증서 서명을 담당하는 루트 CA 인증서를 제공하려면 tls.crt 필드에 입력합니다.

더 나은 적합성을 제공하는 것은 ca.crt 필드를 별도의 CA 시크릿으로 변경합니다. 이렇게 하면 더 넓은 범위의 [...]와 직접 통합할 수 있습니다. 타사 TLS 관리 시스템에서 인증서 생성 및 순환을 처리할 수 있도록 합니다.

또한 Couchbase Server 7.1 및 CAO 2.3을 실행하는 서버는 다음을 사용할 수 있습니다. spec.networking.tls.rootCAs 를 사용하여 신뢰 풀을 만들 수 있습니다. 신뢰 풀을 사용하면 카우치베이스 서버가 여러 CA에 대해 인증서의 유효성을 검사할 수 있습니다. 카우치베이스 서버는 하나의 CA를 사용하면서 클라이언트 인증서를 임의의 수의 개별 CA에 대해 유효성을 검사할 수 있습니다. 

따라서 모든 클라이언트 인증서를 동시에 로테이션할 필요 없이 필요에 따라 클라이언트 인증서를 부분적으로 업데이트할 수 있습니다. CA 정보를 저장하는 비밀은 Kubernetes TLS 표준이므로 수동으로 개입할 필요 없이 CAO가 직접 CA 비밀을 가져올 수 있습니다.

• 읽기 CAO 2.3 개념 에서 자세한 내용을 확인하세요.