15장. Kafka에 대한 액세스 보안
클라이언트가 Kafka 브로커에 대한 액세스를 관리하여 Kafka 클러스터를 보호합니다. Kafka 브로커와 클라이언트 간의 보안 연결은 다음을 포함할 수 있습니다.
- 데이터 교환을 위한 암호화
- ID를 증명하기 위한 인증
- 사용자가 실행하는 작업을 허용하거나 거부할 수 있는 권한 부여
AMQ Streams에서 연결을 보호하려면 리스너 및 사용자 계정을 구성해야 합니다.
- 리스너 구성
Kafka리소스를 사용하여 Kafka 브로커에 대한 클라이언트 연결에 대한 리스너를 구성합니다. 리스너는 mTLS, SCRAM-SHA-512, OAuth 2.0 또는 사용자 지정 인증 방법과 같이 클라이언트가 인증하는 방법을 정의합니다. 보안을 강화하려면 Kafka 브로커와 클라이언트 간의 통신을 보호하도록 TLS 암호화를 구성합니다. Kafka 브로커 구성에서 지원되는 TLS 버전 및 암호화 제품군을 지정하여 TLS 기반 통신을 추가로 보호할 수 있습니다.추가된 보호 계층의 경우
Kafka리소스를 사용하여 간단한 OAuth 2.0, OPA 또는 사용자 정의 권한과 같은 Kafka 클러스터에 대한 권한 부여 방법을 지정합니다.- 사용자 계정
AMQ Streams에서
KafkaUser리소스를 사용하여 사용자 계정 및 인증 정보를 설정합니다. 사용자는 클라이언트를 나타내며 Kafka 클러스터를 인증하고 권한을 부여하는 방법을 결정합니다. 사용자 구성에 지정된 인증 및 권한 부여 메커니즘은 Kafka 구성과 일치해야 합니다. 또한 ACL(액세스 제어 목록)을 정의하여 보다 세분화된 권한 부여를 위해 특정 주제 및 작업에 대한 사용자 액세스를 제어합니다. 보안을 강화하기 위해 바이트 속도 또는 CPU 사용률을 기반으로 Kafka 브로커에 대한 클라이언트 액세스를 제한하려면 사용자 할당량을 지정합니다.사용하는 TLS 버전 및 암호화 제품군을 제한하려면 클라이언트에 생산자 또는 소비자 구성을 추가할 수도 있습니다. 클라이언트의 구성은 브로커에서 활성화된 프로토콜 및 암호화 제품군만 사용해야 합니다.
OAuth 2.0을 사용하여 클라이언트 액세스를 관리하는 경우 사용자 인증 및 권한 부여 인증 정보는 권한 부여 서버를 통해 관리됩니다.
AMQ Streams Operator는 구성 프로세스를 자동화하고 인증에 필요한 인증서를 생성합니다. Cluster Operator는 클러스터 내에서 데이터 암호화 및 인증을 위한 TLS 인증서를 자동으로 설정합니다.
15.1. Kafka의 보안 옵션 링크 복사링크가 클립보드에 복사되었습니다!
Kafka 리소스를 사용하여 Kafka 인증 및 권한 부여에 사용되는 메커니즘을 구성합니다.
15.1.1. 리스너 인증 링크 복사링크가 클립보드에 복사되었습니다!
리스너를 생성할 때 Kafka 브로커에 대한 클라이언트 인증을 구성합니다. Kafka 리소스의 Kafka.spec.kafka.listeners.authentication 속성을 사용하여 리스너 인증 유형을 지정합니다.
OpenShift 클러스터 내부의 클라이언트의 경우 일반 (암호 없이) 또는 tls 내부 리스너를 생성할 수 있습니다. 내부 리스너 유형은 헤드리스 서비스와 브로커 Pod에 지정된 DNS 이름을 사용합니다. 헤드리스 서비스 대신broker ClusterIP 서비스를 사용하여 Kafka를 노출하는 내부 리스너의 cluster-ip 유형을 생성할 수도 있습니다. OpenShift 클러스터 외부의 클라이언트의 경우 외부 리스너를 생성하고 노드 포트,로드 밸런서,인그레스 (Kubernetes만 해당) 또는 경로 (OpenShift만 해당)일 수 있는 연결 메커니즘을 지정합니다.
외부 클라이언트 연결을 위한 구성 옵션에 대한 자세한 내용은 14장. Kafka 클러스터에 대한 클라이언트 액세스 설정 을 참조하십시오.
지원되는 인증 옵션:
- mTLS 인증(TLS가 활성화된 리스너에서만)
- SCRAM-SHA-512 인증
- OAuth 2.0 토큰 기반 인증
- 사용자 정의 인증
- TLS 버전 및 암호화 제품군
선택한 인증 옵션은 Kafka 브로커에 대한 클라이언트 액세스를 인증하는 방법에 따라 다릅니다.
사용자 지정 인증을 사용하기 전에 표준 인증 옵션을 살펴봅니다. 사용자 정의 인증을 사용하면 Kafka에서 지원하는 모든 유형의 인증을 사용할 수 있습니다. 더 많은 유연성을 제공할 수 있지만 복잡성도 추가할 수 있습니다.
그림 15.1. Kafka 리스너 인증 옵션
리스너 인증 속성은 해당 리스너와 관련된 인증 메커니즘을 지정하는 데 사용됩니다.
인증 속성을 지정하지 않으면 리스너에서 해당 리스너를 통해 연결하는 클라이언트를 인증하지 않습니다. 리스너는 인증 없이 모든 연결을 허용합니다.
User Operator를 사용하여 KafkaUsers 를 관리할 때 인증을 구성해야 합니다.
다음 예제에서는 다음을 보여줍니다.
-
SCRAM-SHA-512 인증을 위해 구성된
일반리스너 -
mTLS 인증을 사용하는
tls리스너 -
mTLS 인증을 사용하는
외부리스너
각 리스너는 Kafka 클러스터 내에서 고유한 이름과 포트로 구성됩니다.
브로커에 대한 클라이언트 액세스를 위해 리스너를 구성할 때 포트 9092 이상(9093, 9094 등)을 사용할 수 있지만 몇 가지 예외가 있습니다. 리스너는 인터브로커 통신(9090 및 9091), Prometheus 지표(9404) 및 Cryostat(Java Management Extensions) 모니터링(9999)을 위해 예약된 포트를 사용하도록 구성할 수 없습니다.
리스너 인증 구성의 예
15.1.1.1. mTLS 인증 링크 복사링크가 클립보드에 복사되었습니다!
mTLS 인증은 항상 Kafka 브로커와 Zoo Cryostat Pod 간의 통신에 사용됩니다.
AMQ Streams는 TLS(Transport Layer Security)를 사용하도록 Kafka를 구성하여 상호 인증 없이 Kafka 브로커와 클라이언트 간에 암호화된 통신을 제공할 수 있습니다. 상호 또는 양방향 인증의 경우 서버와 클라이언트 모두 인증서를 제공합니다. mTLS 인증을 구성하면 브로커는 클라이언트(클라이언트 인증)를 인증하고 클라이언트는 브로커(서버 인증)를 인증합니다.
Kafka 리소스의 mTLS 리스너 구성은 다음과 같습니다.
-
TLS 암호화 및 서버 인증을 지정하는 TLS
: true -
authentication.type: tls를 사용하여 클라이언트 인증을 지정합니다.
Cluster Operator가 Kafka 클러스터를 생성할 때 <cluster _name>-cluster-ca-cert라는 이름으로 새 시크릿을 생성합니다. 보안에는 CA 인증서가 포함되어 있습니다. CA 인증서는 PEM 및 PKCS #12 형식입니다. Kafka 클러스터를 확인하려면 클라이언트 구성의 신뢰 저장소에 CA 인증서를 추가합니다. 클라이언트를 확인하려면 사용자 인증서와 키를 클라이언트 구성의 키 저장소에 추가합니다. mTLS용 클라이언트 구성에 대한 자세한 내용은 15.2.2절. “사용자 인증” 을 참조하십시오.
TLS 인증은 한 당사자가 다른 사람의 ID를 인증하는 더 일반적으로 단방향입니다. 예를 들어 웹 브라우저와 웹 서버 간에 HTTPS를 사용하면 브라우저가 웹 서버의 ID 증명을 가져옵니다.
15.1.1.2. SCRAM-SHA-512 인증 링크 복사링크가 클립보드에 복사되었습니다!
SCRAM(Salted Challenge Response Authentication Mechanism)은 암호를 사용하여 상호 인증을 설정할 수 있는 인증 프로토콜입니다. AMQ Streams는 암호화되지 않은 클라이언트 연결 및 암호화된 클라이언트 연결에 대한 인증을 제공하기 위해 SCRAM-SHA-512를 사용하도록 Kafka를 구성할 수 있습니다.
SCRAM-SHA-512 인증을 TLS 연결과 함께 사용하는 경우 TLS 프로토콜은 암호화를 제공하지만 인증에는 사용되지 않습니다.
SCRAM의 다음 속성은 암호화되지 않은 연결에서도 SCRAM-SHA-512를 안전하게 사용할 수 있도록 합니다.
- 암호는 통신 채널을 통해 명확하게 전송되지 않습니다. 대신 클라이언트와 서버는 인증 사용자의 암호를 알고 있음을 증명하기 위해 서로 챌린지가 됩니다.
- 서버와 클라이언트는 각각 인증 교환에 대해 새로운 문제를 생성합니다. 즉, 교환은 재생 공격에 대해 탄력적입니다.
KafkaUser.spec.authentication.type 이 scram-sha-512 로 구성된 경우 User Operator는 대문자 및 소문자 ASCII 문자 및 숫자로 구성된 임의의 12자 암호를 생성합니다.
15.1.1.3. 네트워크 정책 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 AMQ Streams는 Kafka 브로커에서 활성화된 모든 리스너에 대해 NetworkPolicy 리소스를 자동으로 생성합니다. 이 NetworkPolicy 를 사용하면 애플리케이션이 모든 네임스페이스의 리스너에 연결할 수 있습니다. 네트워크 정책을 리스너 구성의 일부로 사용합니다.
네트워크 수준에서 리스너에 대한 액세스를 선택한 애플리케이션 또는 네임스페이스로 제한하려면 networkPolicyPeers 속성을 사용합니다. 각 리스너에는 다른 networkPolicyPeers 구성이 있을 수 있습니다. 네트워크 정책 피어에 대한 자세한 내용은 NetworkPolicyPeer API 참조를 참조하십시오.
사용자 정의 네트워크 정책을 사용하려면 Cluster Operator 구성에서 STRIMZI_NETWORK_POLICY_GENERATION 환경 변수를 false 로 설정할 수 있습니다. 자세한 내용은 9.5절. “Cluster Operator 구성”의 내용을 참조하십시오.
OpenShift 구성은 AMQ Streams에서 네트워크 정책을 사용하려면 ingress NetworkPolicies 를 지원해야 합니다.
15.1.1.4. 리스너 인증서 제공 링크 복사링크가 클립보드에 복사되었습니다!
TLS 암호화가 활성화된 TLS 리스너 또는 외부 리스너에 대해 Kafka 리스너 인증서 라는 자체 서버 인증서를 제공할 수 있습니다. 자세한 내용은 15.3.4절. “TLS 암호화를 위한 자체 Kafka 리스너 인증서 제공”의 내용을 참조하십시오.
15.1.2. Kafka 권한 부여 링크 복사링크가 클립보드에 복사되었습니다!
Kafka 리소스에서 Kafka.spec.kafka.authorization 속성을 사용하여 Kafka 브로커에 대한 인증을 구성합니다. 권한 부여 속성이 없으면 권한 부여가 활성화되지 않으며 클라이언트에 제한이 없습니다. 활성화하면 활성화된 모든 리스너에 권한 부여가 적용됩니다. 권한 부여 방법은 type 필드에 정의됩니다.
지원되는 권한 부여 옵션:
- 간단한 권한 부여
- OAuth 2.0 인증 ( OAuth 2.0 토큰 기반 인증을 사용하는 경우)
- OCI(Open Policy Agent) 권한 부여
- 사용자 정의 권한 부여
그림 15.2. Kafka 클러스터 권한 부여 옵션
15.1.2.1. 슈퍼유저 링크 복사링크가 클립보드에 복사되었습니다!
슈퍼 사용자는 액세스 제한에 관계없이 Kafka 클러스터의 모든 리소스에 액세스할 수 있으며 모든 권한 부여 메커니즘에서 지원됩니다.
Kafka 클러스터의 슈퍼 사용자를 지정하려면 사용자 주체 목록을 SuperUsers 속성에 추가합니다. 사용자가 mTLS 인증을 사용하는 경우 사용자 이름은 CN= 접두사가 붙은 TLS 인증서 제목의 일반 이름입니다. User Operator를 사용하지 않고 mTLS에 자체 인증서를 사용하지 않는 경우 사용자 이름은 전체 인증서 제목입니다. 전체 인증서 주체는 CN=user,OU=my_ou,O=my_org,L=my_location,ST=my_state,C=my_country_code. 존재하지 않는 필드를 생략합니다.
슈퍼 유저를 사용하는 구성의 예