인증 정책

인증 정책 (Authentication Policy)

이 작업은 Istio 인증 정책을 활성화하고, 구성하고, 사용할 때 수행할 수 있는 주요 활동을 다뤄요. 상호 TLS와 최종 사용자 인증을 설정하는 방법을 예시로 배워요.

출처: Istio 문서

본문

이 작업은 Istio 인증 정책을 활성화, 구성, 사용할 때 수행해야 할 주요 활동을 다뤄요. 기본 개념에 대한 자세한 내용은 인증 개요에서 확인하세요.

시작하기 전에 (Before you begin)

  • Istio 인증 정책과 관련 상호 TLS 인증 개념을 이해하세요.
  • 설치 단계에 설명된 대로 default 구성 프로필로 Kubernetes 클러스터에 Istio를 설치하세요.
$ istioctl install --set profile=default

설정 (Setup)

예시에서는 foo와 bar 두 네임스페이스를 사용하고, 두 서비스 httpbin과 curl이 모두 Envoy 프록시와 함께 실행돼요. 또한 legacy 네임스페이스에는 사이드카 없이 실행되는 httpbin과 curl의 두 번째 인스턴스를 사용해요. 작업을 시도할 때 같은 예시를 사용하려면 다음을 실행하세요.

$ kubectl create ns foo
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n foo
$ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n foo
$ kubectl create ns bar
$ kubectl apply -f <(istioctl kube-inject -f @samples/httpbin/httpbin.yaml@) -n bar
$ kubectl apply -f <(istioctl kube-inject -f @samples/curl/curl.yaml@) -n bar
$ kubectl create ns legacy
$ kubectl apply -f @samples/httpbin/httpbin.yaml@ -n legacy
$ kubectl apply -f @samples/curl/curl.yaml@ -n legacy

foo, bar, legacy 네임스페이스의 아무 curl 파드에서 httpbin.foo, httpbin.bar, httpbin.legacy 중 하나로 curl로 HTTP 요청을 보내서 설정을 검증할 수 있어요. 모든 요청은 HTTP 코드 200으로 성공해야 해요. 예를 들어 curl.bar에서 httpbin.foo로의 연결성을 확인하는 명령은 다음과 같아요.

$ kubectl exec "$(kubectl get pod -l app=curl -n bar -o jsonpath={.items..metadata.name})" -c curl -n bar -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
200

이 원라이너 명령은 모든 연결성 조합을 편리하게 순회해요.

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl -s "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 200
curl.legacy to httpbin.bar: 200
curl.legacy to httpbin.legacy: 200

다음 명령으로 시스템에 피어 인증 정책이 없는지 확인하세요.

$ kubectl get peerauthentication --all-namespaces
No resources found

마지막으로 예시 서비스에 적용되는 대상 규칙(destination rules)이 없는지 확인하세요. 기존 대상 규칙의 host: 값을 확인해서 매칭되지 않는지 확인하면 돼요. 예를 들어:

$ kubectl get destinationrules.networking.istio.io --all-namespaces -o yaml | grep "host:"

[!note] Istio 버전에 따라 표시된 것 외에 다른 호스트에 대한 대상 규칙이 보일 수 있어요. 그러나 foo, bar, legacy 네임스페이스의 호스트가 있는 규칙이나 모든 것을 매칭하는 와일드카드 *는 없어야 해요.

자동 상호 TLS (Auto mutual TLS)

기본적으로 Istio는 Istio 프록시로 마이그레이션된 서버 워크로드를 추적하고, 클라이언트 프록시가 해당 워크로드에 자동으로 상호 TLS 트래픽을 보내고, 사이드카가 없는 워크로드에는 평문 트래픽을 보내도록 구성해요. 따라서 프록시가 있는 워크로드 간의 모든 트래픽은 아무것도 하지 않아도 상호 TLS를 사용해요. 예를 들어 httpbin/header에 대한 요청의 응답을 보세요. 상호 TLS를 사용할 때 프록시는 백엔드로 가는 업스트림 요청에 X-Forwarded-Client-Cert 헤더를 주입해요. 해당 헤더의 존재는 상호 TLS가 사용된다는 증거예요. 예를 들어:

$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl -s http://httpbin.foo:8000/headers -s | jq '.headers["X-Forwarded-Client-Cert"][0]' | sed 's/Hash=[a-z0-9]*;/Hash=<redacted>;/'
  "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=<redacted>;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/curl"

서버에 사이드카가 없으면 X-Forwarded-Client-Cert 헤더가 없는데, 이는 요청이 평문임을 의미해요.

$ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metadata.name})" -c curl -n foo -- curl http://httpbin.legacy:8000/headers -s | grep X-Forwarded-Client-Cert

STRICT 모드에서 Istio 상호 TLS 전역적으로 활성화하기

Istio는 프록시와 워크로드 간의 모든 트래픽을 상호 TLS로 자동 업그레이드하지만, 워크로드는 여전히 평문 트래픽을 받을 수 있어요. 전체 메시에 대해 비-상호 TLS 트래픽을 방지하려면 상호 TLS 모드를 STRICT로 설정한 메시 전역 피어 인증 정책을 설정하세요. 메시 전역 피어 인증 정책은 selector가 없어야 하며 루트 네임스페이스에 적용해야 해요. 예를 들어:

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF

[!note] 예시는 istio-system이 루트 네임스페이스라고 가정해요. 설치 중에 다른 값을 사용했다면 istio-system을 사용한 값으로 바꾸세요. 이 피어 인증 정책은 워크로드가 TLS로 암호화된 요청만 수락하도록 구성해요. selector 필드에 값을 지정하지 않으므로 정책은 메시의 모든 워크로드에 적용돼요. 테스트 명령을 다시 실행하세요.

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 000
command terminated with exit code 56
curl.legacy to httpbin.legacy: 200

프록시가 없는 클라이언트인 curl.legacy에서 프록시가 있는 서버인 httpbin.foo 또는 httpbin.bar로의 요청을 제외하고는 요청이 여전히 성공하는 것을 볼 수 있어요. 이는 상호 TLS가 이제 엄격히 요구되지만 사이드카가 없는 워크로드는 이를 준수할 수 없기 때문에 예상된 결과예요.

정리 파트 1

이 세션에서 추가한 전역 인증 정책을 제거하세요.

$ kubectl delete peerauthentication -n istio-system default

네임스페이스 또는 워크로드별 상호 TLS 활성화하기 (Enable mutual TLS per namespace or workload)

네임스페이스 전체 정책 (Namespace-wide policy)

특정 네임스페이스의 모든 워크로드에 대한 상호 TLS를 변경하려면 네임스페이스 전체 정책을 사용하세요. 정책의 사양은 메시 전체 정책과 같지만, metadata 아래에 적용할 네임스페이스를 지정해요. 예를 들어 다음 피어 인증 정책은 foo 네임스페이스에 대해 엄격한 상호 TLS를 활성화해요.

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "default"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT
EOF

이 정책은 foo 네임스페이스의 워크로드에만 적용되므로, 사이드카가 없는 클라이언트(curl.legacy)에서 httpbin.foo로의 요청만 실패하기 시작하는 것을 볼 수 있어요.

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 200
curl.legacy to httpbin.legacy: 200

워크로드별 상호 TLS 활성화하기 (Enable mutual TLS per workload)

특정 워크로드에 대한 피어 인증 정책을 설정하려면 selector 섹션을 구성하고 원하는 워크로드와 매칭되는 레이블을 지정해야 해요. 예를 들어 다음 피어 인증 정책은 httpbin.bar 워크로드에 대해 엄격한 상호 TLS를 활성화해요.

$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT
EOF

다시 프로빙 명령을 실행하세요. 예상대로 curl.legacy에서 httpbin.bar로의 요청이 같은 이유로 실패하기 시작해요.

$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 000
command terminated with exit code 56
curl.legacy to httpbin.legacy: 200

...
curl.legacy to httpbin.bar: 000
command terminated with exit code 56

포트별로 상호 TLS 설정을 세분화하려면 portLevelMtls 섹션을 구성해야 해요. 예를 들어 다음 피어 인증 정책은 포트 8080을 제외한 모든 포트에서 상호 TLS를 요구해요.

$ cat <<EOF | kubectl apply -n bar -f -
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT
  portLevelMtls:
    8080:
      mode: DISABLE
EOF
  1. 피어 인증 정책의 포트 값은 컨테이너의 포트예요.
  2. 포트가 서비스에 바인딩된 경우에만 portLevelMtls를 사용할 수 있어요. 그렇지 않으면 Istio가 이를 무시해요.
$ for from in "foo" "bar" "legacy"; do for to in "foo" "bar" "legacy"; do kubectl exec "$(kubectl get pod -l app=curl -n ${from} -o jsonpath={.items..metadata.name})" -c curl -n ${from} -- curl "http://httpbin.${to}:8000/ip" -s -o /dev/null -w "curl.${from} to httpbin.${to}: %{http_code}\n"; done; done
curl.foo to httpbin.foo: 200
curl.foo to httpbin.bar: 200
curl.foo to httpbin.legacy: 200
curl.bar to httpbin.foo: 200
curl.bar to httpbin.bar: 200
curl.bar to httpbin.legacy: 200
curl.legacy to httpbin.foo: 000
command terminated with exit code 56
curl.legacy to httpbin.bar: 200
curl.legacy to httpbin.legacy: 200

정책 우선순위 (Policy precedence)

워크로드별 피어 인증 정책은 네임스페이스 전체 정책보다 우선해요. 예를 들어 httpbin.foo 워크로드에 대해 상호 TLS를 비활성화하는 정책을 추가하면 이 동작을 테스트할 수 있어요. 이미 foo 네임스페이스의 모든 서비스에 대해 상호 TLS를 활성화하는 네임스페이스 전체 정책을 만들었고, curl.legacy에서 httpbin.foo로의 요청이 실패하는 것을 관찰했다는 점에 주의하세요(위 참조).

$ cat <<EOF | kubectl apply -n foo -f -
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: "overwrite-example"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: DISABLE
EOF

curl.legacy에서 요청을 다시 실행하면 성공 코드(200)가 다시 반환되는 것을 볼 수 있어요. 이는 서비스별 정책이 네임스페이스 전체 정책을 오버라이드함을 확인하는 거예요.

$ kubectl exec "$(kubectl get pod -l app=curl -n legacy -o jsonpath={.items..metadata.name})" -c curl -n legacy -- curl http://httpbin.foo:8000/ip -s -o /dev/null -w "%{http_code}\n"
200

정리 파트 2

위 단계에서 만든 정책을 제거하세요.

$ kubectl delete peerauthentication default overwrite-example -n foo
$ kubectl delete peerauthentication httpbin -n bar

최종 사용자 인증 (End-user authentication)

이 기능을 실험하려면 유효한 JWT가 필요해요. JWT는 데모에 사용할 JWKS 엔드포인트와 일치해야 해요. 이 튜토리얼은 Istio 코드베이스의 테스트 토큰 JWT 테스트와 JWKS 엔드포인트를 사용해요. 또한 편의를 위해 인그레스 게이트웨이를 통해 httpbin.foo를 노출하세요(자세한 내용은 인그레스 작업 참조).

[!note] Istio는 Kubernetes Gateway API를 지원하며, 향후 트래픽 관리의 기본 API로 만들 계획이에요. 다음 지침은 메시에서 트래픽 관리를 구성할 때 Gateway API 또는 Istio 구성 API 중 하나를 선택해서 사용할 수 있게 해줘요. 선호에 따라 Gateway API 또는 Istio APIs 탭 아래의 지침을 따르세요. 참고: Kubernetes Gateway API CRD는 대부분의 Kubernetes 클러스터에 기본으로 설치되지 않으므로, Gateway API를 사용하기 전에 설치되어 있는지 확인하세요.

$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
  kubectl apply --server-side -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.0/experimental-install.yaml

[Istio APIs] 게이트웨이를 구성하세요.

$ kubectl apply -f @samples/httpbin/httpbin-gateway.yaml@ -n foo

인그레스 IP와 포트 확인하기 지침을 따라 INGRESS_PORT와 INGRESS_HOST 환경 변수를 정의하세요. [Gateway API] 게이트웨이를 생성하세요.

$ kubectl apply -f @samples/httpbin/gateway-api/httpbin-gateway.yaml@ -n foo
$ kubectl wait --for=condition=programmed gtw -n foo httpbin-gateway

INGRESS_PORT와 INGRESS_HOST 환경 변수를 설정하세요.

$ export INGRESS_HOST=$(kubectl get gtw httpbin-gateway -n foo -o jsonpath='{.status.addresses[0].value}')
$ export INGRESS_PORT=$(kubectl get gtw httpbin-gateway -n foo -o jsonpath='{.spec.listeners[?(@.name=="http")].port}')

게이트웨이를 통해 테스트 쿼리를 실행하세요.

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

이제 인그레스 게이트웨이에 대해 최종 사용자 JWT를 요구하는 요청 인증 정책을 추가하세요. [Istio APIs]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "[email protected]"
    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.31/security/tools/jwt/samples/jwks.json"
EOF

[Gateway API]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: "jwt-example"
  namespace: foo
spec:
  targetRef:
    kind: Gateway
    group: gateway.networking.k8s.io
    name: httpbin-gateway
  jwtRules:
  - issuer: "[email protected]"
    jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.31/security/tools/jwt/samples/jwks.json"
EOF

정책을 선택하는 워크로드의 네임스페이스, 이 경우 인그레스 게이트웨이에 적용하세요. 권한 헤더에 토큰을 제공하면(암묵적 기본 위치), Istio는 공개 키 세트를 사용해서 토큰을 검증하고, 베어러 토큰이 유효하지 않으면 요청을 거부해요. 그러나 토큰이 없는 요청은 수락돼요. 이 동작을 관찰하려면 토큰 없이, 잘못된 토큰으로, 유효한 토큰으로 각각 요청을 다시 시도하세요.

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

$ curl --header "Authorization: Bearer ***" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
401

$ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.31/security/tools/jwt/samples/demo.jwt -s)
$ curl --header "Authorization: Bearer ***" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
200

JWT 검증의 다른 측면을 관찰하려면 gen-jwt.py 스크립트를 사용해서 다른 발급자, 대상(audience), 만료 날짜 등으로 테스트할 새 토큰을 생성하세요. 스크립트는 Istio 저장소에서 다운로드할 수 있어요.

$ wget --no-verbose https://raw.githubusercontent.com/istio/istio/release-1.31/security/tools/jwt/samples/gen-jwt.py

key.pem 파일도 필요해요.

$ wget --no-verbose https://raw.githubusercontent.com/istio/istio/release-1.31/security/tools/jwt/samples/key.pem

[!note] 시스템에 아직 설치하지 않았다면 jwcrypto 라이브러리를 다운로드하세요. JWT 인증에는 60초 시계 오프셋이 있어요. 즉 JWT 토큰은 구성된 nbf보다 60초 일찍 유효해지고, 구성된 exp 이후 60초 동안 유효하게 유지돼요. 예를 들어 아래 명령은 5초 후에 만료되는 토큰을 만들어요. 보다시피 Istio는 처음에는 해당 토큰으로 요청을 성공적으로 인증하지만, 65초 후에는 거부해요.

$ TOKEN=$(python3 ./gen-jwt.py ./key.pem --expire 5)
$ for i in $(seq 1 10); do curl --header "Authorization: Bearer ***" "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"; sleep 10; done
200
200
200
200
200
200
200
401
401
401

인그레스 게이트웨이(예: 서비스 istio-ingressgateway.istio-system.svc.cluster.local)에 JWT 정책을 추가할 수도 있어요. 이는 개별 서비스용이 아니라 게이트웨이에 바인딩된 모든 서비스에 대한 JWT 정책을 정의할 때 자주 사용돼요.

유효한 토큰 요구하기 (Require a valid token)

유효한 토큰이 없는 요청을 거부하려면 요청 원칙(request principals)이 없는 요청에 대한 DENY 액션을 지정하는 규칙이 있는 인가 정책을 추가하세요. 다음 예시에서 notRequestPrincipals: ["*"]로 표시돼요. 요청 원칙은 유효한 JWT 토큰이 제공될 때만 사용할 수 있어요. 따라서 규칙은 유효한 토큰이 없는 요청을 거부해요. [Istio APIs]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
EOF

[Gateway API]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: foo
spec:
  targetRef:
    kind: Gateway
    group: gateway.networking.k8s.io
    name: httpbin-gateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
EOF

토큰 없이 요청을 다시 시도하세요. 이제 요청은 403 오류 코드로 실패해요.

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403

경로별 유효한 토큰 요구하기 (Require valid tokens per-path)

호스트, 경로, 메서드별로 토큰 요구사항으로 인가를 세분화하려면 인가 정책을 변경해서 /headers에만 JWT를 요구하세요. 이 인가 규칙이 적용되면 $INGRESS_HOST:$INGRESS_PORT/headers에 대한 요청은 403 오류 코드로 실패해요. 다른 모든 경로에 대한 요청은 성공해요. 예를 들어 $INGRESS_HOST:$INGRESS_PORT/ip. [Istio APIs]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/headers"]
EOF

[Gateway API]

$ kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: "frontend-ingress"
  namespace: foo
spec:
  targetRef:
    kind: Gateway
    group: gateway.networking.k8s.io
    name: httpbin-gateway
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/headers"]
EOF

$ curl "$INGRESS_HOST:$INGRESS_PORT/headers" -s -o /dev/null -w "%{http_code}\n"
403

$ curl "$INGRESS_HOST:$INGRESS_PORT/ip" -s -o /dev/null -w "%{http_code}\n"
200

정리 파트 3

  1. 인증 정책을 제거하세요.
$ kubectl -n istio-system delete requestauthentication jwt-example
  1. 인가 정책을 제거하세요.
$ kubectl -n istio-system delete authorizationpolicy frontend-ingress
  1. 토큰 생성기 스크립트와 키 파일을 제거하세요.
$ rm -f ./gen-jwt.py ./key.pem
  1. 후속 작업을 탐구할 계획이 없다면 테스트 네임스페이스를 삭제해서 모든 리소스를 제거할 수 있어요.
$ kubectl delete ns foo bar legacy

더 알아보기 (Learn more)

  • 인증 개념에 대한 자세한 내용은 인증 개요 문서를 참고하세요.
  • 최종 사용자 인증의 JWT 규칙과 옵션에 대해서는 RequestAuthentication API 참조를 확인하세요.