[Istio] Security Concepts

출처: https://istio.io/v1.17/docs/concepts/security/#implicit-enablement

Security Overview

모놀리식 애플리케이션을 원자적 서비스로 분해하면 민첩성, 확장성, 서비스 재사용성을 크게 높일 수 있지만, 동시에 보안 요구 사항도 복잡해집니다.

• 트래픽 암호화 – 중간자 공격(MITM)을 방지하려면 서비스 간 통신을 TLS로 보호해야 합니다.
• Mutual TLS 및 세분화된 정책 – 유연한 서비스 접근 제어를 위해 필요합니다.
• 감사(Audit) – “누가‧언제‧무엇을 했는지” 기록해야 합니다.

Security Overview

Istio Security는 데이터·엔드포인트·통신·플랫폼을 내부‧외부 위협으로부터 보호하기 위한 포괄적인 보안 기능을 제공합니다.
핵심 기능은 다음과 같습니다.

• 강력한 아이덴티티
• 정교한 정책(Policy)
• 투명한 TLS 암호화
• AAA(인증·인가·감사) 도구

목표

• 기본 보안 – 애플리케이션 코드나 인프라를 수정하지 않고도 보호
• 심층 방어 – 기존 보안 시스템과 통합해 다층 방어 구현
• 제로 트러스트 네트워크 – 불신 네트워크 환경에서도 안전하게 동작

---

고수준 아키텍처(High‑level architecture)

Istio 보안은 여러 컴포넌트로 구성됩니다.

1. CA(Certificate Authority) – 키 및 인증서 관리
2. 구성 API 서버 - 프록시에 다음 3가지 배포
   1. 인증
   2. 인가
   3. Secure Naming 정보
3. PEP(Policy Enforcement Point) – 사이드카·경계 프록시가 클라이언트-서버 간 통신 보호
4. Envoy 확장 – 텔레메트리 및 감사 처리

컨트롤 플레인은 API 서버 구성을 수신해 데이터 플레인의 PEP(Envoy)을 설정합니다.

Security Architecture

---

Istio Identity

아이덴티티는 보안 인프라의 핵심입니다. 워크로드 간 통신 초기에 양측은 자격 증명에 아이덴티티 정보를 담아 교환하여 상호 인증을 수행합니다.

• 클라이언트는 서버 인증서의 서비스 계정을 Secure Naming 매핑과 대조해 허가된 워크로드인지 확인합니다.
• 서버는 클라이언트 아이덴티티를 기반으로 인가(Authorization)·과금·감사를 수행할 수 있습니다.

Istio 아이덴티티 모델은 1급 개체인 서비스 아이덴티티를 사용합니다. 이는 사람 사용자, 단일 워크로드, 워크로드 그룹 등으로 유연하게 표현할 수 있습니다.

 

플랫폼별 예시

• Kubernetes – Kubernetes 서비스 어카운트
• GCE – GCP 서비스 어카운트
• 온프레미스 – 사용자 지정 서비스 어카운트, 서비스 이름 등

---

Identity & Certificate Management

Istio는 모든 워크로드에 X.509 인증서를 안전하게 배포하고 주기적으로 교체합니다. Istio agent(Envoy 프록시와 함께 실행)가 istiod와 협력하여 자동으로 키·인증서를 관리합니다.

Identity Provisioning Workflow

 

Istio는 다음 흐름을 통해 키와 인증서를 프로비저닝합니다.

1. istiod가 인증서 서명 요청(CSR) 을 처리하는 gRPC 서비스를 제공합니다.
2. Istio agent가 개인 키 및 CSR을 생성한 다음 자격 증명과 함께 CSR을 istiod로 전송하여 서명을 받습니다.
3. CA가 CSR을 검증 후 인증서를 서명·발급합니다.
4. Envoy가 Envoy SDS(Secret Discovery Service) API를 통해 인증서·키를 수신합니다.
5. Istio agent가 인증서 만료를 모니터링하며 주기적으로 교체합니다.

---

Authentication

Istio는 두 가지 인증 방식을 제공합니다.

• Peer Authentication – 서비스 - 서비스 인증 (Mutual TLS)
  • 서비스 코드 변경 없이 활성화할 수 있습니다.
  • 클러스터와 클라우드 간 상호 운용성을 지원하기 위한 역할을 나타내는 강력한 ID를 각 서비스에 제공합니다.
  • 서비스 간 통신을 보호합니다.
  • 키와 인증서 생성, 배포, 순환을 자동화하는 키 관리 시스템을 제공합니다.
• Request Authentication – 최종 사용자(End-User) 요청 인증 (JWT 검증)
  • Istio는 JSON 웹 토큰(JWT) 검증을 통한 요청 수준 인증과 다음과 같은 맞춤형 인증 공급자 또는 OpenID Connect 공급자를 사용한 간소화된 개발자 경험을 제공합니다.
    • ORY Hydra
    • Keycloak
    • Auth0
    • Firebase Auth
    • Google Auth

모든 경우에 Istio는 커스텀 쿠버네티스 API를 통해 Istio 구성 저장소에 인증 정책을 저장합니다. Istio는 각 프록시의 인증 정책을 최신 상태로 유지하고, 필요한 경우 키도 함께 업데이트합니다. 또한, Istio는 허용 모드 인증을 지원하여 정책 변경이 보안 태세에 미치는 영향을 사전에 파악할 수 있도록 지원합니다.

Mutual TLS 인증 흐름

Istio는 Envoy 프록시 로 구현된 클라이언트 및 서버 측 PEP를 통해 서비스 간 통신을 터널링합니다. 워크로드가 상호 TLS 인증을 사용하여 다른 워크로드로 요청을 전송하면 요청은 다음과 같이 처리됩니다.

1. 클라이언트 트래픽을 로컬 사이드카 Envoy로 리다이렉트
2. 클라이언트 Envoy - 서버 Envoy 간 Mutual TLS 핸드셰이크 및 Secure Naming 검사
3. TLS 세션 수립 후 트래픽 전달
4. 서버 Envoy가 인가 후 백엔드로 로컬 TCP 전송

Istio는 최소 TLS 버전을 TLSv1_2로 설정하며, 다음 Cipher Suite를 지원합니다.

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
AES256-GCM-SHA384
AES128-GCM-SHA256

Permissive mode

평문과 Mutual TLS 트래픽을 모두 허용합니다. 이 기능은 상호 TLS 온보딩 환경을 크게 향상시키고 점진적 마이그레이션을 지원합니다.

Secure Naming

보안 네이밍 정보는 서버 ID를 서비스 이름에 매핑합니다. 서비스 이름은 검색 서비스 또는 DNS를 통해 검색됩니다. ID A를 서비스 이름 B에 매핑하면 "A가 서비스 B를 실행할 권한이 있음"을 의미하며, 해당 정보를 제공하여 인증을 강화합니다. 제어 평면은 API 서버를 감시하고 보안 네이밍 매핑을 생성하여 PEP에 안전하게 배포합니다.

보안 네이밍이 중요한 이유: 예시 시나리오

• 데이터 저장소 서비스를 운영하는 합법적인 서버는 인프라 팀 ID만 사용한다고 가정합니다.
  • 악의적인 사용자가 테스트 팀 ID의 인증서와 키를 탈취
  • 이 사용자는 테스트 팀 ID로 위조된 서버를 배포해, 클라이언트의 데이터를 가로채려 함
  • DNS 스푸핑, BGP/경로 하이재킹, ARP 스푸핑 등을 통해 트래픽을 위조 서버로 리디렉션할 수 있음
  • 클라이언트가 데이터 저장소 서비스에 요청을 보낼 때, 서버 인증서에서 테스트 팀 ID를 추출함
  • 클라이언트는 보안 네이밍 정보를 조회해 테스트 팀이 데이터 저장소를 운영할 권한이 없는 것을 확인함
  • 인증이 실패하여, 악의적인 사용자의 위조 서버가 차단됨

한계: HTTP/HTTPS가 아닌 트래픽의 경우

• 보안 네이밍은 DNS 스푸핑 자체를 막지 못함
• DNS 스푸핑이 발생하면 공격자가 서비스의 대상 IP를 변조할 수 있음.
• TCP 트래픽에는 호스트 정보가 포함되어 있지 않아, Envoy는 오직 IP 기반으로 라우팅함
• 클라이언트 측 Envoy가 트래픽을 받기 전에도 DNS 스푸핑이 발생할 수 있음
• 결과적으로, 하이재킹된 IP로 트래픽이 라우팅될 수 있음

Authorization architecture

Istio 인가(Authorization) 기능은 mesh, 네임스페이스, 워크로드 단위로 세밀한 접근 제어를 제공합니다. AuthorizationPolicy라는 단일 CRD를 사용하며, Envoy 프록시에서 네이티브로 고성능 집행이 이뤄집니다.

• Istio 메시에서 요청을 수신하는 워크로드에 대한 인증 요구 사항은 피어 인증 정책과 요청 인증 정책을 통해 지정합니다.
• 메시 운영자는 .yaml 파일로 정책을 정의하며, 배포 후 Istio 구성 저장소에 저장됩니다.
• Istio 컨트롤러는 구성 저장소를 지속적으로 감시합니다.
• 정책 변경 시, 새 정책은 PEP(Policy Enforcement Point)에 필요한 인증 메커니즘 수행 방법을 알리는 구성으로 변환됩니다.
• Control Plane은 공개 키를 가져와 JWT 검증에 사용하거나, Istio 시스템이 관리하는 키와 인증서 경로를 제공해 상호 TLS를 위해 애플리케이션 Pod에 설치합니다.
• Istio는 대상 엔드포인트에 구성을 비동기적으로 전송하며, 프록시가 구성을 수신하면 즉시 새로운 인증 요구 사항이 적용됩니다.
• 요청을 보내는 클라이언트 서비스는 필요한 인증 메커니즘을 준수해야 합니다.
• 요청 인증 시 애플리케이션은 JWT 자격 증명을 획득해 요청에 포함해야 합니다.
• 피어 인증 시 Istio는 두 PEP 간 트래픽을 자동으로 상호 TLS(mTLS)로 업그레이드합니다.
• 상호 TLS 모드가 비활성화된 경우 일반 텍스트 통신을 유지하며, 이 동작은 대상 규칙을 통해 명시적으로 제어할 수 있습니다.

Authentication Architecture

Istio는 두 가지 유형의 인증을 모두 포함한 ID와 해당되는 경우 자격 증명의 다른 클레임을 다음 계층인 권한 부여 로 출력합니다 .

Authentication policies

이 섹션에서는 Istio 인증 정책의 작동 방식에 대해 자세히 설명합니다. 아키텍처 섹션에서 언급했듯이 인증 정책은 서비스가 수신하는 요청에 적용됩니다. 상호 TLS에서 클라이언트 측 인증 규칙을 지정하려면 DestinationRule에 TLSSettings를 지정해야 합니다. 

다른 Istio 구성과 마찬가지로 .yaml 파일에서 인증 정책을 지정할 수 있습니다. kubectl을 사용하여 정책을 배포합니다. 다음 인증 정책 예시는 app:reviews 레이블이 있는 워크로드에 대한 전송 인증이 상호 TLS를 사용해야 함을 지정합니다.

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: "example-peer-policy"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: reviews
  mtls:
    mode: STRICT

Policy storage

Istio는 루트 네임스페이스에 메시 범위 정책을 저장합니다. 이러한 정책은 메시의 모든 워크로드에 적용되는 빈 selector를 갖습니다. 네임스페이스 범위가 있는 정책은 해당 네임스페이스에 저장되며, 해당 네임스페이스 내의 워크로드에만 적용됩니다. selector 필드를 구성하면, 구성한 조건과 일치하는 워크로드에만 인증 정책이 적용됩니다.

피어 및 요청 인증 정책은 각각 종류(PeerAuthentication 및 RequestAuthentication)별로 별도로 저장됩니다.

Selector field

피어 및 요청 인증 정책은 selector 필드를 사용하여 정책이 적용되는 워크로드의 레이블을 지정합니다. 다음 예는 app:product-page 레이블이 있는 워크로드에 적용되는 정책의 selector 필드를 보여줍니다.

selector:
  matchLabels:
    app: product-page

 

selector 필드에 값을 제공하지 않으면 Istio는 정책을 해당 정책의 저장소 범위에 있는 모든 워크로드와 일치시킵니다. 따라서 selector 필드는 정책의 범위를 지정하는 데 도움이 됩니다.

 

• 메시 전체 정책: 선택자 필드가 비어 있거나 비어 있는 루트 네임스페이스에 지정된 정책입니다.
• 네임스페이스 전체 정책: 선택자 필드가 비어 있거나 비어 있는 루트가 아닌 네임스페이스에 지정된 정책입니다.
• 워크로드별 정책: 선택자 필드가 비어 있지 않은 일반 네임스페이스에 정의된 정책입니다.

피어 및 요청 인증 정책은 선택자 필드에 대해 동일한 계층 원칙을 따르지만 Istio는 이를 약간 다른 방식으로 결합하고 적용합니다.

 

메시 전체 피어 인증 정책은 하나만 있을 수 있으며, 네임스페이스당 네임스페이스 전체 피어 인증 정책도 하나만 있을 수 있습니다. 동일한 메시 또는 네임스페이스에 대해 여러 개의 메시 또는 네임스페이스 전체 피어 인증 정책을 구성하는 경우 Istio는 최신 정책을 무시합니다. 두 개 이상의 워크로드별 피어 인증 정책이 일치하는 경우 Istio는 가장 오래된 정책을 선택합니다.

 

Istio는 다음 순서에 따라 각 워크로드에 가장 좁은 범위의 매칭 정책을 적용합니다.

1. 워크로드별
2. 네임스페이스 전체
3. 메시 전체

Istio는 모든 매칭 요청 인증 정책을 결합하여 마치 단일 요청 인증 정책에서 생성된 것처럼 작동하도록 할 수 있습니다. 따라서 하나의 메시 또는 네임스페이스에 여러 개의 메시 전체 또는 네임스페이스 전체 정책을 적용할 수 있습니다. 하지만 여러 개의 메시 전체 또는 네임스페이스 전체 요청 인증 정책을 적용하는 것은 피하는 것이 좋습니다.

 

 

(정리 중...........)

---

Authorization architecture

권한 부여 정책은 서버 측 Envoy 프록시에서 인바운드 트래픽에 대한 액세스 제어를 시행합니다. 각 Envoy 프록시는 런타임에 요청을 승인하는 권한 부여 엔진을 실행합니다. 요청이 프록시에 수신되면 권한 부여 엔진은 현재 권한 부여 정책과 비교하여 요청 컨텍스트를 평가하고 승인 결과(ALLOW 또는 DENY)를 반환합니다. 운영자는 .yaml 파일을 사용하여 Istio 권한 부여 정책을 지정합니다.

Authorization Architecture

1. 클라이언트 요청이 서버 사이드 Envoy에 도착합니다.
2. Envoy의 Authorization Engine이 정책을 평가한 뒤 ALLOW 또는 DENY 결정을 내립니다.
3. 허용된 요청만 백엔드 애플리케이션으로 전달됩니다.

Implicit enablement

Istio의 권한 부여 기능은 설치 후 사용할 수 있으므로 명시적으로 활성화할 필요는 없습니다. 워크로드에 대한 액세스 제어를 시행하려면 권한 부여 정책을 적용합니다.

권한 부여 정책이 적용되지 않은 워크로드의 경우 Istio는 모든 요청을 허용합니다.

권한 부여 정책은 ALLOW, DENY 및 CUSTOM 작업을 지원합니다. 필요에 따라 각기 다른 작업을 가진 여러 정책을 적용하여 워크로드에 대한 액세스를 보호할 수 있습니다.

 

동일 워크로드에 AuthorizationPolicy CR이 한 개라도 존재하면, 해당 워크로드는 암묵적으로 인가 체크가 “활성화”됩니다. 다시 말해, 정책이 정의되면 기본 동작은 거부(Deny‑by‑default)가 되고, 명시적으로 허용해야 접근할 수 있습니다.

 

Istio는 CUSTOM, DENY, ALLOW 순서로 계층별로 일치하는 정책을 확인합니다. 각 작업 유형에 대해 Istio는 먼저 해당 작업이 적용된 정책이 있는지 확인한 다음, 요청이 정책 사양과 일치하는지 확인합니다. 요청이 계층 중 하나의 정책과 일치하지 않으면 다음 계층으로 이동합니다.

Authorization Policy Precedence

 

---

Authorization policies

Policy Target

• metadata.namespace – 정책이 속한 네임스페이스. 루트 네임스페이스(예: istio-system)에 두면 mesh 전역에 적용할 수 있습니다.
• selector – 레이블 셀렉터로 특정 워크로드(Deployment, Pod 등)에만 정책 적용이 가능합니다.

Value matching

필드 값은 아래 방식으로 매칭할 수 있습니다.

• 정확 매치 – "productpage"
• 접두어 매치 – "product*"
• 접미어 매치 – "*page"
• 존재 매치 – "*" (값이 존재하기만 하면 일치)

Exclusion matching

not* 접미사의 필드를 사용해 부정 조건을 줄 수 있습니다.

from:
  notNamespaces: ["kube-system"]

allow‑nothing, deny‑all, allow‑all 정책

• allow‑nothing – 아무 AuthorizationPolicy도 없으면 모든 요청을 허용(이전 Istio 1.5 이하), 최신 버전은 기본
  거부가 적용되어 “allow‑nothing”과 동일 의미가 됩니다.
• deny‑all – 다음 예시는 모든 접근을 명시적으로 거부합니다.

  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: deny-all
  spec:
    {}
  

• allow‑all – rules: []로 빈 규칙 배열을 주면 모든 요청 허용.

Custom conditions

when 블록을 이용해 추가 Istio 어트리뷰트 조건을 선언할 수 있습니다.

when:
- key: request.headers[x-custom]
  values: ["vip"]

인증된 ID · 미인증 ID

• 인증된 ID(principals) – Mutual TLS 인증서 또는 JWT 토큰에서 추출한 서비스/엔드유저 ID.
• 미인증 ID – 인증 정보가 없는 요청. principals: ["*"]만 지정하면 “인증된 ID만 허용” 의미.

---

Using Istio Authorization on plain TCP protocols

HTTP 전용 필드(method, path 등)를 제외하면, 평문 TCP 트래픽에도 동일한 AuthorizationPolicy를 적용할 수 있습니다. TCP 포트, IP, 네임스페이스, 프린서플 기반 조건으로 제어가 가능합니다.

---

Mutual TLS 종속성

다음 필드는 Mutual TLS가 활성화되어야 일치 조건으로 사용할 수 있습니다.

• source.principal
• source.namespaces
• requestedServerName

따라서 권장 구성은 PeerAuthentication 리소스에서 STRICT 모드로 Mutual TLS를 전면 활성화하고, 그 위에 인가 정책을 설계하는 것입니다.

 

 

(정리 중...)

---

Learn more

• Authentication Tasks
• Authorization Tasks
• Security Policy Examples
• Common Security Problems & Troubleshooting