Azure Kubernetes Application Network 보안 개요(미리 보기)

중요합니다

AKS 미리 보기 기능은 셀프 서비스에서 사용할 수 있습니다(옵트인 방식). 미리 보기는 "있는 그대로" 및 "사용 가능한 상태로" 제공되며 서비스 수준 계약 및 제한적 보증에서 제외됩니다. AKS 미리 보기의 일부는 고객 지원팀에서 최선을 다해 지원합니다. 따라서 이러한 기능은 프로덕션 용도로 사용할 수 없습니다. 자세한 내용은 다음 지원 문서를 참조하세요.

Azure Kubernetes Application Network는 mTLS(자동 상호 TLS) 및 ID 기반 권한 부여를 통해 연결된 AKS(Azure Kubernetes Service) 클러스터의 서비스 간 통신을 보호합니다. 워크로드 ID 발급 및 인증서 발급, 갱신, 유효성 검사를 관리하여, 수동 구성이 필요 없이 FIPS 규격의 전송 중 암호화를 통해 암호화되고 인증된 명시적 권한의 서비스 간 통신을 가능하게 합니다.

이 문서에서는 mTLS, 워크로드 ID, 인증서 관리 및 권한 부여 정책을 포함하여 Azure Kubernetes Application Network의 보안 기능에 대한 개요를 제공합니다. 또한 Azure Kubernetes Application Network 환경에서 보안 통신을 구현하기 위한 제한 사항 및 다음 단계를 간략하게 설명합니다.

제한점

  • 인증서는 현재 Azure Kubernetes Application Network 관리 CA(인증 기관)에서 발급되며 공용 CA에 연결되지 않습니다.

mTLS

Application Network는 mTLS를 사용하여 워크로드 간에 ID 기반의 암호화된 통신을 제공합니다. Application Network 연결된 클러스터의 각 서비스는 해당 ID를 증명하고 동일한 Application Network의 다른 서비스와 신뢰할 수 있는 암호화된 연결을 설정할 수 있는 인증서를 자동으로 받습니다. 전송 중인 암호화는 FIPS 규격 암호화를 사용합니다.

mTLS 마이그레이션 전략

Application Network는 현재 암호화된 트래픽과 암호화되지 않은 트래픽을 모두 허용합니다. 이 접근 방식을 사용하면 기존 워크로드가 정상적으로 작동하는 반면 새 워크로드 또는 업데이트된 워크로드는 보안 통신을 위해 mTLS를 자동으로 사용합니다. 즉, 가동 중지 시간 없이 워크로드 전체에서 보안 통신을 위해 mTLS를 채택할 수 있습니다. 마이그레이션이 완료되면 인증이 적용되도록 엄격한 모드로 변경할 수 있습니다.

Azure Kubernetes Application Network에서 mTLS의 이점

Azure Kubernetes Application Network의 mTLS는 다음을 지원합니다.

  • 전송 중인 데이터 보호: 모든 서비스 간 트래픽을 자동으로 암호화할 수 있습니다(FIPS 규격).
  • 서비스 ID 확인: 각 워크로드에는 고유한 Application Network 관리 루트 및 중간 인증서가 있습니다.
  • 작업 간소화: Application Network는 사용자에 대한 인증서 발급, 회전 및 해지를 처리합니다.

인증서 관리

Azure Kubernetes Application Network는 mTLS에 사용되는 인증서를 발급하고 유지 관리하는 Azure Key Vault에서 지원되는 인증서 관리를 제공합니다. 이 서비스는 동일한 Application Network 리소스에 연결된 모든 AKS 클러스터에서 공유 신뢰 경계를 설정합니다.

Application Network는 프로비전, 갱신 및 회전을 포함하여 루트 및 중간 인증서의 전체 인증서 수명 주기를 자동으로 관리합니다. 이렇게 하면 워크로드 ID가 유효하게 유지되고 시간이 지남에 따라 통신이 안전하게 유지됩니다. 인증서를 수동으로 만들거나 저장하거나 회전할 필요가 없습니다.

다음 다이어그램에서는 루트 CA, 중간 CA 및 워크로드 인증서를 구성하여 연결된 클러스터 간에 신뢰를 설정하는 방법을 보여 주는 Application Network의 인증서 계층 구조를 보여 줍니다.

연결된 클러스터 간에 신뢰를 설정하기 위해 루트 CA, 중간 CA 및 워크로드 인증서를 구성하는 방법을 보여 주는 Azure Kubernetes Application Network의 인증서 계층 구조를 보여 주는 다이어그램의 스크린샷.

인증서 계층 구조 및 수명 주기

Application Network 리소스를 만들면 루트 CA 가 Application Network의 신뢰 앵커 역할을 하도록 프로비전됩니다. AKS 클러스터가 Application Network를 멤버로 조인하면 Application Network는 Application Network 루트 CA에서 서명한 해당 멤버에 대한 중간 인증서 를 발급합니다. 연결된 각 AKS 클러스터는 Application Network 관리 중간 인증서를 사용하여 해당 클러스터의 워크로드에 수명이 짧은 워크로드 인증서 를 발급합니다.

모든 워크로드 인증서는 애플리케이션 네트워크 루트 CA에서 트러스트를 상속하여 리소스 간에 통합 트러스트 경계를 유지 관리합니다. 루트 및 중간 인증서의 회전은 가동 중지 시간 또는 트래픽 중단을 일으키지 않고 사용자를 위해 투명하게 처리됩니다. 이 관리되는 계층 구조는 각 인증서의 유효성을 자동으로 유지하면서 애플리케이션 네트워크의 모든 클러스터에서 일관되고 검증 가능한 신뢰를 보장합니다.

모든 멤버 클러스터에서 네임스페이스 istio-root-cert아래의 구성 맵 applink-system 에서 루트 CA 인증서를 가져올 수 있습니다.

인증서 유형 및 회전 기간

인증서 유형 Scope 유효 기간 회전 기간 Purpose
루트 CA Azure Kubernetes Application Network 12개월 6개월 Azure Kubernetes Application Network에 연결된 모든 클러스터에 대한 신뢰 경계 설정
중간 CA 클러스터 90일 45일 해당 클러스터 내의 워크로드에 대한 워크로드 인증서 발급
워크로드 인증서 업무량 24시간 12시간 워크로드를 인증하고 서비스 간 통신을 보호합니다.

워크로드 ID 및 권한 부여

애플리케이션이 증가함에 따라 서비스는 동일한 배포 내의 여러 네임스페이스 및 환경에서 안전하게 통신해야 하는 경우가 많습니다. 인증서를 관리하고 각 서비스가 통신하는 사람을 확인할 수 있는지 확인하면 복잡하고 오류가 발생하기 쉽습니다. Azure Kubernetes Application Network는 워크로드 ID를 자동으로 할당하고 관리하여 이러한 오버헤드를 제거합니다.

애플리케이션 네트워크에 연결된 환경 내에서 워크로드는 네임스페이스 내부 및 전체에서 안전하게 통신합니다. 각 서비스를 신뢰할 수 있고 인증할 수 있도록 Application Network는 모든 워크로드에 해당 네임스페이스 및 서비스 계정을 나타내는 확인 가능한 ID 를 할당합니다.

각 애플리케이션 네트워크 워크로드는 해당 네임스페이스 및 서비스 계정을 포함하는 SPIFFE 형식의 고유 ID를 자동으로 받습니다. ID의 형식은 다음과 같습니다.

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

이 ID는 워크로드 인증서에 포함되며 다른 워크로드와 통신할 때 서비스의 ID를 증명하는 데 사용됩니다. Azure Kubernetes Application Network는 Istio 권한 부여 정책과 함께 이 SPIFFE 기반 ID 모델을 사용하여 통신할 수 있는 서비스에 대한 명확하고 일관된 규칙을 정의할 수 있습니다.

액세스 정책 정의

Istio AuthorizationPolicies 를 사용하여 환경 내에서 통신할 수 있는 워크로드를 제어할 수 있습니다. 이러한 정책을 사용하면 네트워크 위치 또는 IP 주소가 아닌 확인된 워크로드 ID를 기반으로 액세스를 정의할 수 있습니다. 이 방법을 사용하면 서비스가 노드 간에 확장 및 이동하더라도 일관된 액세스 제어를 적용할 수 있습니다. 예를 들어 다음 예제와 같이 정책의 보안 주체 목록에서 SPIFFE ID를 참조하여 신뢰할 수 있는 네임스페이스의 특정 게이트웨이 또는 워크로드만 서비스를 호출하도록 허용할 수 있습니다.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

정책 디자인 지침

권한 부여 정책을 디자인할 때는 다음 모범 사례를 염두에 두어야 합니다.

  • 의도하지 않은 네임스페이스 간 액세스를 방지하려면 항상 네임스페이스와 서비스 계정을 모두 지정합니다.
  • 주체를 사용하여 세분화된 액세스를 위한 명시적 워크로드 ID를 정의합니다.
  • 네임스페이스를 사용하여 적절한 경우 더 광범위한 신뢰 경계를 정의합니다.
  • 클러스터 또는 환경에서 액세스 권한을 부여할 수 있으므로 네임스페이스가 없는 서비스 계정 이름과만 일치하는 규칙을 사용하지 마세요.
  • Kubernetes AuthorizationPolicies 와 결합하여 NetworkPolicies ID 기반 및 네트워크 기반 격리를 모두 적용합니다.

메모

Azure Kubernetes Application Network 권한 부여는 IP 주소가 아닌 확인된 워크로드 ID를 기반으로 합니다. 이렇게 하면 워크로드가 노드 간에 확장되거나 이동하더라도 일관된 적용이 보장됩니다.

Azure Kubernetes Application Network 관리 ID, 인증서 및 정책 컨트롤을 결합하여 ID 기반의 최소 권한 서비스 통신을 구현하여 클러스터 간 워크로드 간에 인증되고 암호화되고 명시적으로 권한이 부여된 트래픽을 보장할 수 있습니다.

Azure Kubernetes Application Network에 대한 자세한 내용은 다음 문서를 참조하세요.