보안 정책 예제

보안 정책 예제 (Security policy examples)

Istio 보안 정책을 사용하는 일반적인 패턴을 보여주는 페이지예요. JWT 발급자, 네임스페이스 격리, mTLS 강제 등의 실용적인 예제 정책을 배워요.

출처: Istio 문서

본문

배경

이 페이지는 Istio 보안 정책을 사용하는 일반적인 패턴을 보여줘요. 배포에서 유용하게 쓰거나 예제 정책에 대한 빠른 참조로 사용할 수 있어요.

여기서 보여주는 정책들은 예시일 뿐이며, 적용 전에 실제 환경에 맞게 변경해야 해요.

또한 인증 및 권한 부여 작업을 읽고 보안 정책 사용을 더 자세히 실습해 보세요.

호스트별로 다른 JWT 발급자 요구하기

JWT 검증은 ingress 게이트웨이에서 흔하며, 호스트에 따라 다른 JWT 발급자를 요구하고 싶을 수 있어요. request authentication 정책에 더해 세밀한 JWT 검증을 위해 authorization policy를 사용할 수 있어요.

JWT principal이 일치하면 주어진 호스트에 대한 접근을 허용하려면 다음 정책을 사용하세요. 다른 호스트에 대한 접근은 항상 거부돼요.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: jwt-per-host
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
        # the JWT token must have issuer with suffix "@example.com"
        requestPrincipals: ["*@example.com"]
    to:
    - operation:
        hosts: ["example.com", "*.example.com"]
  - from:
    - source:
        # the JWT token must have issuer with suffix "@another.org"
        requestPrincipals: ["*@another.org"]
    to:
    - operation:
        hosts: [".another.org", "*.another.org"]

네임스페이스 격리

다음 두 정책은 네임스페이스 foo에서 엄격한 mTLS를 활성화하고, 같은 네임스페이스의 트래픽을 허용해요.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: foo-isolation
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]

ingress 예외가 있는 네임스페이스 격리

다음 두 정책은 네임스페이스 foo에서 엄격한 mTLS를 활성화하고, 같은 네임스페이스와 ingress 게이트웨이의 트래픽을 허용해요.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: foo
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        namespaces: ["foo"]
    - source:
        principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]

권한 부여 레이어에서 mTLS 요구 (심층 방어)

PeerAuthentication을 STRICT로 구성했지만, 권한 부여 레이어에서 트래픽이 실제로 mTLS로 보호되고 있는지 추가 검사(즉 심층 방어, defense in depth)로 확인하고 싶어요.

다음 정책은 principal이 비어 있으면 요청을 거부해요. 평문이 사용되면 principal은 비어 있어요. 즉, 이 정책은 principal이 비어 있지 않으면 요청을 허용해요. "*"는 비어 있지 않은 매치를 의미하며, notPrincipals와 함께 사용하면 빈 principal에 매칭돼요.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-mtls
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notPrincipals: ["*"]

`DENY` 정책으로 필수 권한 부여 검사 요구하기

반드시 충족되어야 하고 더 허용적인 다른 ALLOW 정책으로 우회될 수 없는 필수 권한 부여 검사를 요구하려면 DENY 정책을 사용할 수 있어요. DENY 정책이 ALLOW 정책보다 우선하고 ALLOW 정책보다 먼저 요청을 거부할 수 있기 때문에 작동해요.

request authentication 정책에 더해 필수 JWT 검증을 강제하려면 다음 정책을 사용하세요. 이 정책은 요청 principal이 비어 있으면 요청을 거부해요. JWT 검증이 실패하면 요청 principal이 비어요. 즉, 이 정책은 요청 principal이 비어 있지 않으면 요청을 허용해요. "*"는 비어 있지 않은 매치를 의미하며, notRequestPrincipals와 함께 사용하면 빈 요청 principal에 매칭돼요.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

마찬가지로 다음 정책을 사용해 필수 네임스페이스 격리를 요구하면서 ingress 게이트웨이의 요청은 허용할 수 있어요. 이 정책은 네임스페이스가 foo가 아니고 principal이 cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account가 아니면 요청을 거부해요. 즉, 이 정책은 네임스페이스가 foo이거나 principal이 cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account인 경우에만 요청을 허용해요.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: ns-isolation-except-ingress
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        notNamespaces: ["foo"]
        notPrincipals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]

더 알아보기 (Learn more)

Istio 보안 구성 섹션

보안 정책 예제