7.5. 송신 방화벽


7.5.1. 프로젝트의 송신 방화벽 보기

클러스터 관리자는 기존 송신 방화벽의 이름을 나열하고 특정 송신 방화벽에 대한 트래픽 규칙을 볼 수 있습니다.

7.5.1.1. EgressFirewall 오브젝트 보기

클러스터의 EgressFirewall 오브젝트를 볼 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressFirewall 오브젝트의 이름을 보려면 다음 명령을 입력합니다.

    $ oc get egressfirewall --all-namespaces
  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다.

    $ oc describe egressfirewall <policy_name>

    출력 예

    Name:		default
    Namespace:	project1
    Created:	20 minutes ago
    Labels:		<none>
    Annotations:	<none>
    Rule:		Allow to 1.2.3.0/24
    Rule:		Allow to www.example.com
    Rule:		Deny to 0.0.0.0/0

7.5.2. 프로젝트의 송신 방화벽 편집

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

7.5.2.1. EgressFirewall 오브젝트 편집

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
  2. 선택 사항: 송신 네트워크 방화벽을 만들 때 EgressFirewall 오브젝트의 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다.

    $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressFirewall 오브젝트를 바꿉니다. 업데이트된 EgressFirewall 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다.

    $ oc replace -f <filename>.yaml

7.5.3. 프로젝트에서 송신 방화벽 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

7.5.3.1. EgressFirewall 오브젝트 제거

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다.

    $ oc get -n <project> egressfirewall
  2. 다음 명령을 입력하여 EgressFirewall 오브젝트를 삭제합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다.

    $ oc delete -n <project> egressfirewall <name>

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

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

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

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

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

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

참고

송신 방화벽은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 송신 방화벽 규칙의 영향을 받지 않습니다.

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

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

송신 방화벽에 0.0.0.0/0에 대한 거부 규칙이 포함된 경우 OpenShift Container Platform API 서버에 대한 액세스 권한이 차단됩니다. 각 IP 주소에 대해 허용 규칙을 추가하거나 송신 정책 규칙에서 nodeSelector 유형 허용 규칙을 사용하여 API 서버에 연결해야 합니다.

다음 예제에서는 API 서버 액세스를 확인하는 데 필요한 송신 방화벽 규칙의 순서를 보여줍니다.

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 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

7.5.4.1.1. 송신 방화벽의 제한

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

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 프로젝트당 최대 50개의 규칙이 있는 최대 하나의 EgressFirewall 오브젝트를 정의할 수 있습니다.
  • Red Hat OpenShift Networking에서 공유 게이트웨이 모드가 있는 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 반환 수신 응답이 송신 방화벽 규칙의 영향을 받습니다. 송신 방화벽 규칙이 ingress 응답 대상 IP를 삭제하면 트래픽이 삭제됩니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상됩니다. 결과적으로 모든 외부 네트워크 트래픽이 삭제되어 조직에 보안 위험이 발생할 수 있습니다.

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

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

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

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

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

  • 도메인 이름 업데이트는 TTL(Time To- Live) 기간에 따라 폴링됩니다. 기본적으로 기간은 30분입니다. 송신 방화벽 컨트롤러가 로컬 이름 서버에 도메인 이름을 쿼리할 때 응답에 TTL이 포함되고 TTL이 30분 미만이면 컨트롤러는 해당 DNS 이름의 기간을 반환된 값으로 설정합니다. 각 DNS 이름은 DNS 레코드의 TTL이 만료된 후에 쿼리됩니다.
  • Pod는 필요한 경우 동일한 로컬 이름 서버에서 도메인을 확인해야 합니다. 확인하지 않으면 송신 방화벽 컨트롤러와 Pod에 의해 알려진 도메인의 IP 주소가 다를 수 있습니다. 호스트 이름의 IP 주소가 다르면 송신 방화벽이 일관되게 적용되지 않을 수 있습니다.
  • 송신 방화벽 컨트롤러와 Pod는 동일한 로컬 이름 서버를 비동기적으로 폴링하기 때문에 Pod가 송신 컨트롤러보다 먼저 업데이트된 IP 주소를 얻을 수 있으며 이로 인해 경쟁 조건이 발생합니다. 현재 이런 제한으로 인해 EgressFirewall 오브젝트의 도메인 이름 사용은 IP 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽 정책에서 DNS 이름을 사용하는 것은 CoreDNS를 통한 로컬 DNS 확인에는 영향을 미치지 않습니다.

그러나 송신 방화벽 정책이 도메인 이름을 사용하고 외부 DNS 서버가 영향을 받는 Pod의 DNS 확인을 처리하는 경우 DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 포함해야 합니다.

7.5.4.1.3.1. DNS 확인 및 와일드카드 도메인 이름 확인

DNS 레코드와 연결된 IP 주소가 자주 변경되거나 송신 방화벽 정책 규칙에 와일드카드 도메인 이름을 지정할 수 있는 상황이 있을 수 있습니다.

이 경우 OVN-Kubernetes 클러스터 관리자는 송신 방화벽 정책 규칙에 사용되는 각 고유 DNS 이름에 대해 DNSNameResolver 사용자 정의 리소스 오브젝트를 생성합니다. 이 사용자 정의 리소스는 다음 정보를 저장합니다.

중요

송신 방화벽 규칙에 대한 DNS 확인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

DNSNameResolver CR 정의의 예

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com. 1
status:
  resolvedNames:
  - dnsName: www.example.com. 2
    resolvedAddress:
    - ip: "1.2.3.4" 3
      ttlSeconds: 60 4
      lastLookupTime: "2023-08-08T15:07:04Z" 5

1
DNS 이름입니다. 표준 DNS 이름 또는 와일드카드 DNS 이름일 수 있습니다. 와일드카드 DNS 이름의 경우 DNS 이름 확인 정보에는 와일드카드 DNS 이름과 일치하는 모든 DNS 이름이 포함됩니다.
2
spec.name 필드와 일치하는 확인된 DNS 이름입니다. spec.name 필드에 와일드카드 DNS 이름이 포함된 경우 확인 시 와일드카드 DNS 이름과 일치하는 표준 DNS 이름이 포함된 여러 dnsName 항목이 생성됩니다. 와일드카드 DNS 이름도 성공적으로 확인할 수 있는 경우 이 필드는 와일드카드 DNS 이름도 저장합니다.
3
DNS 이름과 연결된 현재 IP 주소입니다.
4
마지막 TTL(Time-to-live) 기간입니다.
5
마지막 조회 시간입니다.

DNS 확인 중에 쿼리의 DNS 이름이 DNSNameResolver CR에 정의된 이름과 일치하는 경우 이전 정보는 CR status 필드에 적절하게 업데이트됩니다. 실패한 DNS 와일드카드 이름 조회의 경우 요청은 기본 TTL 30분 후에 다시 시도합니다.

OVN-Kubernetes 클러스터 관리자는 EgressFirewall 사용자 정의 리소스 오브젝트의 업데이트를 감시하고 해당 업데이트가 발생할 때 해당 송신 방화벽 정책과 연결된 DNSNameResolver CR을 생성, 수정 또는 삭제합니다.

주의

DNSNameResolver 사용자 정의 리소스를 직접 수정하지 마십시오. 이로 인해 송신 방화벽의 원치 않는 동작이 발생할 수 있습니다.

7.5.4.2. EgressFirewall CR(사용자 정의 리소스) 오브젝트

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 Allow 규칙 또는 Deny 규칙입니다.

다음 YAML은 EgressFirewall CR 오브젝트를 설명합니다.

EgressFirewall 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name> 1
spec:
  egress: 2
    ...

1
오브젝트의 이름은 default이어야 합니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.
7.5.4.2.1. EgressFirewall 규칙

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 사용자는 CIDR 형식, 도메인 이름에서 IP 주소 범위를 선택하거나 nodeSelector 를 사용하여 송신 트래픽을 허용하거나 거부할 수 있습니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type> 1
  to: 2
    cidrSelector: <cidr> 3
    dnsName: <dns_name> 4
    nodeSelector: <label_name>: <label_value> 5
  ports: 6
      ...

1
규칙 유형입니다. 값은 Allow 또는 Deny여야 합니다.
2
cidrSelector 필드 또는 dnsName 필드를 지정하는 송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
DNS 도메인 이름입니다.
5
레이블은 사용자가 정의하는 키/값 쌍입니다. 레이블은 Pod와 같은 오브젝트에 연결됩니다. nodeSelector 를 사용하면 하나 이상의 노드 레이블을 선택하고 Pod에 연결할 수 있습니다.
6
선택 사항: 규칙에 대한 네트워크 포트 및 프로토콜 컬렉션을 설명하는 스탠자입니다.

포트 스탠자

ports:
- port: <port> 1
  protocol: <protocol> 2

1
80 또는 443과 같은 네트워크 포트. 이 필드의 값을 지정하는 경우 protocol의 값도 지정해야 합니다.
2
네트워크 프로토콜. 값은 TCP, UDP 또는 SCTP여야 합니다.
7.5.4.2.2. EgressFirewall CR 오브젝트의 예

다음 예는 여러 가지 송신 방화벽 정책 규칙을 정의합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress: 1
  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
1
송신 방화벽 정책 규칙 오브젝트의 컬렉션입니다.

다음 예에서는 트래픽이 TCP 프로토콜 및 대상 포트 80 또는 임의의 프로토콜 및 대상 포트 443을 사용하는 경우 172.16.1.1 IP 주소에서 호스트에 대한 트래픽을 거부하는 정책 규칙을 정의합니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1
    ports:
    - port: 80
      protocol: TCP
    - port: 443
7.5.4.2.3. EgressFirewall의 nodeSelector 예

클러스터 관리자는 nodeSelector 를 사용하여 라벨을 지정하여 클러스터의 노드에 대한 송신 트래픽을 허용하거나 거부할 수 있습니다. 레이블은 하나 이상의 노드에 적용할 수 있습니다. 다음은 region=east 라벨이 있는 예입니다.

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow
작은 정보

노드 IP 주소당 수동 규칙을 추가하는 대신 노드 선택기를 사용하여 송신 방화벽 뒤의 Pod가 호스트 네트워크 pod에 액세스할 수 있는 레이블을 생성합니다.

7.5.4.3. 송신 방화벽 정책 오브젝트 생성

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressFirewall 오브젝트가 정의되어 있는 경우 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.
  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다.

    $ oc create -f <policy_name>.yaml -n <project>

    다음 예제에서는 project1이라는 프로젝트에 새 EgressFirewall 오브젝트가 생성됩니다.

    $ oc create -f default.yaml -n project1

    출력 예

    egressfirewall.k8s.ovn.org/v1 created

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.