15.5. 프로젝트에 대한 송신 방화벽 구성


클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

15.5.1. 프로젝트에서 송신 방화벽이 작동하는 방식

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

EgressFirewall CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
  • 포트 번호
  • 다음 프로토콜 중 하나인 프로토콜: TCP, UDP 및 SCTP
중요

송신 방화벽에 0.0.0.0/0에 대한 거부 규칙이 포함된 경우 OpenShift Container Platform API 서버에 대한 액세스 권한이 차단됩니다. Pod에서 OpenShift Container Platform API 서버에 계속 액세스할 수 있도록 하려면 다음 예와 같이 API 서버가 송신 방화벽 규칙에서 수신 대기하는 IP 주소 범위를 포함해야 합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace> 1
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range> 2
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0 3
    type: Deny
1
송신 방화벽의 네임스페이스입니다.
2
OpenShift Container Platform API 서버를 포함하는 IP 주소 범위입니다.
3
글로벌 거부 규칙은 OpenShift Container Platform API 서버에 액세스할 수 없습니다.

API 서버의 IP 주소를 찾으려면 oc get ep kubernetes -n default 를 실행합니다.

자세한 내용은 BZ#1988324에서 참조하십시오.

주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

15.5.1.1. 송신 방화벽의 제한

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 프로젝트당 최대 50개의 규칙이 있는 최대 하나의 EgressFirewall 오브젝트를 정의할 수 있습니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상되고 모든 외부 네트워크 트래픽이 삭제될 수 있습니다.

Egress 방화벽 리소스는 kube-node-lease,kube-public,kube-system, openshift - 프로젝트에서 생성할 수 있습니다.

15.5.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

15.5.1.3. DNS(Domain Name Server) 확인 작동 방식

송신 방화벽 정책 규칙에서 DNS 이름을 사용하는 경우 도메인 이름의 적절한 확인에는 다음 제한 사항이 적용됩니다.

  • 도메인 이름 업데이트는 로컬 권한이 없는 서버가 반환한 도메인의 TTL(Time to Live) 값을 기준으로 폴링됩니다.
  • Pod는 필요한 경우 동일한 로컬 이름 서버에서 도메인을 확인해야 합니다. 확인하지 않으면 송신 방화벽 컨트롤러와 Pod에 의해 알려진 도메인의 IP 주소가 다를 수 있습니다. 호스트 이름의 IP 주소가 다르면 송신 방화벽이 일관되게 적용되지 않을 수 있습니다.
  • 송신 방화벽 컨트롤러와 Pod는 동일한 로컬 이름 서버를 비동기적으로 폴링하기 때문에 Pod가 송신 컨트롤러보다 먼저 업데이트된 IP 주소를 얻을 수 있으며 이로 인해 경쟁 조건이 발생합니다. 현재 이런 제한으로 인해 EgressFirewall 오브젝트의 도메인 이름 사용은 IP 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽은 Pod가 DNS 확인을 위해 Pod가 있는 노드의 외부 인터페이스에 항상 액세스할 수 있도록 합니다.

송신 방화벽 정책에서 도메인 이름을 사용하고 로컬 노드의 DNS 서버에서 DNS 확인을 처리하지 않으면 Pod에서 도메인 이름을 사용하는 경우, DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 추가해야 합니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.