Openflow BYOC - 사용자 지정 인그레스 설정

Openflow BYOC - 사용자 지정 인그레스 설정

자체 AWS 계정 내에서 관리되는 사용자 지정 인그레스 솔루션으로 Openflow BYOC 배포를 설정하는 고려 사항과 단계를 설명합니다.

출처: Snowflake 문서

본문

이 주제에서는 자체 AWS 계정 내에서 관리되는 사용자 지정 인그레스 솔루션으로 Openflow BYOC 배포를 설정하는 데 필요한 고려 사항과 단계를 설명합니다.

이점

Openflow BYOC 배포를 위한 사용자 지정 인그레스는 조직에 다음을 제공합니다:

  • VPN 또는 사설 네트워크로만 접근을 제한할 수 있는 네트워크 수준 제한으로 보안 강화.
  • 보안 및 규정 준수 요구 사항을 충족하기 위해 Openflow에 접근하는 데 사용되는 URL과 TLS 인증서를 완전히 제어.

고려 사항

Snowflake 관리 인그레스의 경우 Openflow가 필요한 DNS 레코드, 공용 로드 밸런서를 만들고 BYOC 배포의 Openflow 런타임에 대한 TLS 인증서를 관리합니다.

사용자 지정 인그레스를 활성화하면 Openflow는 더 이상 외부 DNS 레코드를 자동으로 관리하지 않고, 공용 로드 밸런서를 자동으로 만들지 않으며, Openflow 런타임의 인증서를 더 이상 관리하지 않습니다. 이러한 리소스는 자체 AWS 계정에서 관리해야 합니다.

Snowflake Openflow에서 사용자 지정 인그레스 구성

  1. 배포 생성 중에 사용자 지정 인그레스를 활성화합니다.

    배포 생성 중에 Custom ingress를 활성화하고 Hostname 필드에 원하는 정규화된 도메인 이름(FQDN)을 지정합니다.

  2. 이 DNS 레코드를 관리하고 이 FQDN에 대한 TLS 인증서를 만들 수 있어야 합니다. snowflakecomputing.com의 하위 도메인을 사용하지 마세요.

  3. FQDN에 프로토콜 https:// 또는 끝에 슬래시 /를 포함해서는 안 됩니다.

  4. 예를 들어 openflow01.your-domain.org를 지정하면 "My Runtime"이라는 런타임에 https://openflow01.your-domain.org/my-runtime/nifi/로 접근하게 됩니다.

  5. CloudFormation 템플릿을 다운로드합니다. 이 파일에는 Openflow가 사용자 지정 인그레스 도메인으로 실행하는 데 필요한 모든 설정이 들어 있습니다.

AWS에서 사용자 지정 인그레스 구성

참고: {deployment-key}는 특정 배포를 위해 Openflow가 만들고 관리하는 클라우드 리소스에 적용되는 Openflow 고유 식별자를 나타냅니다. 이는 CloudFormation 템플릿의 DataPlaneKey 매개변수에 있으며, 배포에 대한 View Details 메뉴 옵션에서도 볼 수 있습니다.

  1. Openflow 배포의 프라이빗 서브넷에 다음 태그를 추가합니다:

    • Key: kubernetes.io/role/internal-elb
  2. Value: 1

  3. 프라이빗 서브넷이 다른 EKS 클러스터에서도 사용된다면 Openflow 클러스터 이름으로도 태그를 지정해야 합니다. 이렇게 하면 Openflow가 다른 로드 밸런서와 함께 로드 밸런서를 만들 수 있습니다.

    • Key: kubernetes.io/cluster/{deployment-key}
  4. Value: 1

  5. CloudFormation 템플릿을 업로드합니다. Openflow가 내부 네트워크 로드 밸런서를 만들 때까지 약 30분 정도 기다리세요.

    AWS 콘솔의 EC2 » Load Balancers에서 내부 네트워크 로드 밸런서를 찾을 수 있습니다.

  6. 로드 밸런서 이름은 runtime-ingress-{deployment-key}입니다.

  7. Openflow가 관리하는 AWS 내부 네트워크 로드 밸런서의 내부 IP 주소를 얻습니다.

    EC2 » Load Balancers에서 세부 정보 페이지로 이동하여 로드 밸런서의 DNS 이름을 복사합니다.

  8. agent EC2 인스턴스(openflow-agent-{deployment-key})에 로그인하여 nslookup {openflow-load-balancer-dns-name} 명령을 실행합니다.

  9. Openflow가 관리하는 AWS 내부 네트워크 로드 밸런서의 IP 주소를 복사합니다. 이것들은 다음 단계에서 만들 로드 밸런서의 대상 그룹 대상입니다.

  10. TLS 인증서를 프로비저닝합니다.

    Openflow 런타임 UI로 트래픽을 처리할 로드 밸런서에 대한 TLS 인증서를 얻습니다. AWS Certificate Manager(ACM)로 인증서를 생성하거나 기존 인증서를 가져올 수 있습니다.

  11. Openflow가 관리하는 AWS 내부 네트워크 로드 밸런서로 트래픽을 라우팅할 네트워크 로드 밸런서를 만듭니다.

    AWS 계정에서 다음 구성으로 Network Load Balancer를 만듭니다:

    • Name: custom-ingress-external-{deployment-key}와 같은 명명 규칙을 권장합니다. 여기서 {deployment-key}는 Openflow 배포의 키입니다.
  12. Type: Network Load Balancer

  13. Scheme: 요구 사항에 따라 Internal 또는 Internet-facing.

  14. VPC: 배포의 VPC를 선택.

  15. Availability Zones: Openflow 배포가 실행 중인 두 가용 영역을 모두 선택.

  16. Subnets: Internal Load Balancer에는 VPC의 프라이빗 서브넷을, Internet-facing Load Balancer에는 공용 서브넷을 선택.

  17. Security groups: 포트 443 트래픽을 허용하는 보안 그룹을 선택하거나 생성.

  18. Default SSL/TLS server certificate: SSL/TLS 인증서를 가져오기.

  19. Target group: 다음 설정으로 새 대상 그룹을 생성:

    • Target type: IP addresses
  20. Protocol: TLS

  21. Port: 443

  22. VPC: VPC가 배포와 일치하는지 확인.

  23. 이전 단계에서 얻은 Openflow가 만든 내부 네트워크 로드 밸런서의 IP 주소를 대상으로 입력하고 Include as pending으로 선택.

  24. 로드 밸런서가 생성되면 DNS 이름을 복사하여 다음 단계에서 사용.

  25. 네트워크 로드 밸런서 생성에 대한 자세한 내용은 Create a Network Load Balancer를 참조하세요.

사용자 지정 인그레스 FQDN을 AWS 로드 밸런서의 DNS 이름에 매핑하는 DNS CNAME 레코드를 만듭니다.

  • Route 53의 자세한 DNS 구성 지침은 Create records in Route 53을 참조하세요.
  1. Openflow 배포가 Deployments 페이지에 상태 Active로 표시됩니다.
  2. Openflow 배포에서 런타임을 만듭니다.
  3. 런타임이 Active가 되면 런타임 이름을 클릭하거나 View canvas 메뉴 옵션을 사용하여 런타임의 UI에 접근합니다.
  4. Openflow는 배포 생성 중에 지정한 호스트 이름으로 런타임으로 안내합니다. 예: https://openflow01.your-domain.org/my-runtime/nifi/.

문제 해결

다음 섹션에서는 사용자 지정 인그레스의 일반적인 문제에 대한 문제 해결 단계를 제공합니다. 이러한 확인을 수행한 후에도 여전히 문제가 발생하면 Snowflake Support 케이스를 제출하세요.

로드 밸런서 대상 상태 확인

네트워크 로드 밸런서의 대상 그룹에는 Openflow가 관리하는 내부 네트워크 로드 밸런서의 IP 주소가 대상으로 나열되어야 합니다. 모든 대상은 Healthy로 표시되어야 합니다. 대상을 Unhealthy로 표시하면 다음 확인을 사용하여 트래픽이 실패하는 지점을 좁혀 보세요.

  1. AWS 콘솔에서 EC2 » Load Balancers를 엽니다.

  2. Kubernetes 클러스터로 인그레스를 관리하는 Openflow 관리 로드 밸런서를 찾습니다. 이 로드 밸런서의 이름은 runtime-ingress-{deployment-key}입니다.

  3. Resource map 탭에서 해당 로드 밸런서의 대상 상태를 검토합니다.

  4. Openflow 관리 로드 밸런서가 활성화되지 않았거나 Unhealthy 대상이 있으면:

    Openflow 관리 로드 밸런서와 BYOC 클러스터 사이의 트래픽이 차단되었거나 클러스터 내부 서비스가 준비되지 않았을 수 있습니다.

  5. openflow-agent-{deployment-key} EC2 인스턴스에서 ./diagnostics.sh를 실행하여 진단 번들을 생성하고 Snowflake Support 케이스에 첨부합니다.

  6. Openflow 관리 로드 밸런서가 활성화되어 있고 대상이 Healthy이면 자체 로드 밸런서의 대상 상태를 확인합니다.

  7. 자체 로드 밸런서의 대상이 Unhealthy이면 로드 밸런서에서 Openflow 관리 로드 밸런서로 가는 경로가 가장 가능성 높은 문제입니다:

    • 대상 그룹의 IP 주소가 잘못되었거나 오래되었습니다. Openflow 관리 로드 밸런서는 시간이 지나면서 바뀔 수 있는 여러 IP 주소를 노출합니다. 최신 값을 얻으려면 Openflow 관리 로드 밸런서의 DNS 이름으로 nslookup을 실행하세요. 필요한 경우 로드 밸런서의 대상을 업데이트하세요.
  8. 보안 그룹 규칙. Openflow 관리 로드 밸런서의 보안 그룹 인바운드 규칙이 자체 로드 밸런서의 TCP 443을 허용하는지 확인하세요. 로드 밸런서가 포트 443에서 Openflow 로드 밸런서에 도달할 수 없으면 트래픽이 실패할 수 있습니다.

브라우저 보안 차단

사용자 지정 인그레스의 일부 문제는 기업 브라우저 보안, 방화벽 또는 사용자 지정 호스트 이름으로의 트래픽을 차단하거나 검사하는 웹 프록시로 인해 발생합니다. 이러한 정책은 AWS 로드 밸런서 구성과 별개입니다. AWS 로드 밸런서가 Healthy 대상을 보고해도 사용자가 Openflow UI를 열 수 없을 수 있습니다.

로드 밸런서를 통한 Openflow 서비스 연결을 확인하려면:

  1. AWS 콘솔에서 EC2 » Load Balancers를 열어 트래픽을 제공하는 로드 밸런서의 DNS 이름과 사용자 지정 인그레스 도메인 이름의 TLS 인증서를 얻습니다.

    이것은 runtime-ingress-{deployment-key} 로드 밸런서가 아닙니다.

  2. openflow-agent-{deployment-key} EC2 인스턴스에서 로드 밸런서를 통해 Openflow 배포로의 연결을 확인합니다. 명령을 실행하세요:

curl -kv https://{your-load-balancer-dns-name}

명령이 예상 인증서 정보와 성공적인 404 상태 코드 응답을 출력하면 Openflow 배포로의 연결을 성공적으로 확인한 것입니다. 3. 명령이 시간 초과되거나 오류를 반환하면 Snowflake Support 케이스를 만들고 Openflow Agent 인스턴스에서 ./diagnostics.sh를 실행하여 생성한 진단 번들을 첨부하세요. 4. Openflow Agent 인스턴스에서 사용자 지정 인그레스 FQDN의 DNS CNAME 레코드도 확인할 수 있습니다. 명령을 실행하세요:

source ~/.env && nslookup $DOMAIN

명령이 사용자 지정 인그레스 도메인 이름에 대해 TLS 종료를 수행하는 로드 밸런서의 IP 주소를 반환하면 DNS CNAME 레코드를 성공적으로 확인한 것입니다. 5. 명령 결과가 없으면 DNS CNAME 레코드가 올바르게 구성되지 않은 것입니다. 사용자 지정 인그레스 FQDN의 DNS 레코드를 확인하고 로드 밸런서의 DNS 이름을 가리키는지 확인하세요.

Openflow Agent가 로드 밸런서의 DNS를 통해 성공적으로 연결되었고 DNS CNAME 레코드를 확인했다면, 보안 정책이나 방화벽이 브라우저에서 Openflow BYOC 배포로 가는 트래픽을 차단하고 있을 가능성이 큽니다. 보안 팀과 협력하여 사용자 지정 인그레스 FQDN을 허용 목록에 추가하세요.

더 알아보기 (Learn more)