Istio mtls 사용

step 1:전제

Kubernetes 1.17.0 버 전

Istio 1.6.0 버 전,배치 시 사용mtls

임 의 서 비 스 를 제공 합 니 다.여기 저 는 자바 서 비 스 를 썼 습 니 다.모 의 장면Sleep서비스 방문Java서비스

step 2:PeerAuthentication CRD 해석PeerAuthentication유량 이 터널 을 통 해 도착 하 는 지 정의SideCar

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  #     
  #        ，       istio root     
  #           ，
  #      Service   ，   Service        DestinationRule,    matchLabels    ，           Service   
  namespace: foo
spec:
  #      Service，     WorkLoad/    
  #       selector       namespace               
  selector:
    matchLabels:
      app: finance
  mtls:
    # mode     
    # 1: UNSET      ，     ，     PERMISSIVE   
    # 2: DISABLE        
    # 3: PERMISSIVE	         mTLS   
    # 4: STRICT	      mTLS   （             TLS） 
    mode: UNSET
  #         TLS   
  portLevelMtls:
    8080:
      mode: DISABLE

step 3:시작 예시
step 3.1:사용자 정의 자바 예제mtls네 임 스페이스 생 성 두 개pod각각 주입SideCar,legacy네 임 스페이스 생 성pod불 주입SideCar

$ kubectl apply -f <(istioctl kube-inject -f ./deployment-v1.yaml) -n mtls
$ kubectl apply -f <(istioctl kube-inject -f ~/istio-1.6.0/samples/sleep/sleep.yaml) -n mtls
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy

배포 검증:

[root@node4 mtls]# kubectl get pod -nlegacy -owide
NAME                       READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
httpbin-779c54bf49-ng6hf   1/1     Running   0          10s   192.168.33.141   node5              
[root@node4 mtls]# kubectl get pod -nmtls -owide
NAME                                     READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
java-service-deployv1-7c4d786879-f4nxp   2/2     Running   0          9m6s    192.168.139.11   node6              
sleep-77747b8698-t7h92                   2/2     Running   0          6m36s   192.168.33.147   node5

테스트 접근,두 네 임 스페이스 의 sleep 서비스 접근 을 통 해 두 네 임 스페이스 가 모두httpbin서비스 에 접근 할 수 있 음 을 알 수 있 습 니 다.

[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n mtls -o jsonpath={.items..metadata.name}) -c sleep -n mtls -- curl http://java-service:8080/demo/service/test
      v1 
[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..metadata.name}) -n legacy -c sleep -- curl http://java-service.mtls.svc.cluster.local:8080/demo/service/test
      v1

3.1.1:정책 설정
3.1.2 격자 범위 설정 정책

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

테스트 접근,두 네 임 스페이스 의 sleep 서비스 접근,현재 네 임 스페이스Sleep만 접근 할 수 있 습 니 다.

[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n mtls -o jsonpath={.items..metadata.name}) -c sleep -n mtls -- curl http://java-service:8080/demo/service/test
      v1 
[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n legacy -o jsonpath={.items..metadata.name}) -n legacy -c sleep -- curl http://java-service.mtls.svc.cluster.local:8080/demo/service/test
curl: (56) Recv failure: Connection reset by peer
command terminated with exit code 56

우 리 는default아래 에 하나의pod를 만 들 고 자동 으로 주입 하여 두 개의 주입sidecar작업 부하 사이 에 접근 할 수 있 는 지 확인 합 니 다.

[root@node4 mtls]# kubectl apply -f 
serviceaccount/sleep unchanged
service/sleep unchanged
deployment.apps/sleep configured

[root@node4 mtls]# kubectl get pod -n default | grep sleep
sleep-77747b8698-d8r9z                 2/2     Running   0          160m

[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n default -o jsonpath={.items..metadata.name}) -n default -c sleep -- curl http://java-service.mtls.svc.cluster.local:8080/demo/service/test
      v1

두 개의 주입sidecar을 볼 수 있 는 작업 부하 간 네트워크 문 은 아무런 문제 가 없다.아래 정부 에서 제공 한 예 시 를 방문 할 수 있 는 이 유 는 이미 지적 되 었 다.
3.1.2 네 임 스페이스 단계 정책
잠시 후 보충...

step 3.2:공식 제공foo및bar네 임 스페이스 의sleep,httpbin모두 자동 주입 을 시 작 했 고pod어떠한 주입 도 열지 않 았 다.

$ 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/sleep/sleep.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/sleep/sleep.yaml) -n bar
$ kubectl create ns legacy
$ kubectl apply -f samples/httpbin/httpbin.yaml -n legacy
$ kubectl apply -f samples/sleep/sleep.yaml -n legacy

서로 접근 하 는 데 문제 가 없습니다.인증 정책 이 열 리 지 않 았 습 니 다.

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

3.2.1:정책 설정
주의:주입legacy의sidecar의pod사이 의 모든 유량 을 사용 합 니 다service.예 를 들 어 TLS에 대한 응답 을 요청 합 니 다.사용httpbin/header시 에이 전 트 는 TLS요청 헤드 를 백 엔 드 상류 에 주입 하여 요청 합 니 다.요청 헤더 의 존재 증명 사용x-forward-client-cert

[root@node4 mtls]# kubectl exec $(kubectl get pod -l app=sleep -n foo -o jsonpath={.items..metadata.name}) -c sleep -n foo -- curl http://httpbin.foo:8000/headers -s | grep X-Forwarded-Client-Cert
    "X-Forwarded-Client-Cert": "By=spiffe://cluster.local/ns/foo/sa/httpbin;Hash=e73aeed3b40e36adef02331bacbc00e2c24d5ebcaaf5f730c3d3d89bef78b3b5;Subject=\"\";URI=spiffe://cluster.local/ns/foo/sa/sleep"

주입 되 지 않 은 TLSsidecar은 존재 하지 않 으 며,직접 명문 전송 을 사용한다.

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

3.2.2 격자 범위 설정 정책
양 방향 인증 시작pod모드
주의:Istio 는 sidecar 와 service 간 의 모든 트 래 픽 을 자동 으로STRICT으로 업그레이드 하지만 TLS명문 트 래 픽 을 받 을 수 있 습 니 다.전체 격자 의 비service를 방지 하기 위해 격자 범위 내의 대등한 인증 전략 을 설정 하고 TLS모드 를 TLS로 설정 합 니 다.격자 범위 의 대등한 인증 정책 이 있어 서 는 안 됩 니 다STRICT.루트 이름 공간 에 적용 해 야 합 니 다.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

위 에서 피 어 투 피 어 인증 정책 에 효과 가 있 습 니 다.격자 에 있 는 모든selector을 사용service만 요청 하도록 설정 합 니 다.이것 은TLS 필드 에 지정 한 값 이 없 기 때문에 이 정책 은 격자 에 있 는 모든selector에 적 용 됩 니 다.
재 테스트

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

service네 임 스페이스 에서 온 요청sleep.legacy을 제외 하고 모두 성공 했다.이 는 예상 결과 에 부합 한다.주입sleep.legacysidecar의sidecarpod만 이 성공 을 요청 할 수 있 기 때문이다.
양 방향 인증 업데이트service모드

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: PERMISSIVE

이때 인증 정책 은 명문,비밀문서 두 가지 요청 방식 결 과 를 허용 합 니 다.

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

3.2.3 네 임 스페이스 범위 설정 정책
모든 네 임 스페이스 나PERMISSIVE네 임 스페이스 범위 정책 을 사용 하 는service네 임 스페이스 내 모든 TLSservice을 실행 하려 면 네 임 스페이스 범위 의 전략 을 사용 하 십시오.정책 의 규범 은 격자 범위 정책 과 같 습 니 다. TLS필드 에서 사용 할 네 임 스페이스 를 지정 해 야 합 니 다.예 를 들 어 아래 의 대등한 인증 정책 은metadata네 임 스페이스foo의STRICT를 사용 합 니 다.
양 방향 인증 시작 TLS모드

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

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

이 정책 은STRICT네 임 스페이스foo에 적용 되 기 때문에service(무sleep.legacy에서sidecar 까지 의 요청 이 실 패 했 습 니 다.
서비스 에 양 방향 인증 설정
특정httpbin에 대등한 인증 정책 을 설정 하려 면Service필드 를 설정 하고 필요 한selector와 일치 하 는 탭 을 지정 해 야 합 니 다.Service는Istio의 출구Service트 래 픽 TLS등급 전략 을 취 합 할 수 없 으 며,이 럴 때 설정Service이 이러한 행 위 를 관리 해 야 한다.
예 를 들 어 다음 대등한 인증 전략 과destinationrule은DestinationRule에 엄격 한httpbin을 사용 합 니 다.지정 TLSService

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "httpbin"
spec:
  host: "httpbin.bar.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

테스트 명령 을 다시 실행 합 니 다.예상 과 달리httpbin.bar부터sleep.legacy까지 의 요청 은 같은 이유 로 실패했다.

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

포트 에 따라 양 방향 mtls 설정
아래 의 대등한 인증 정책 은 모든 포트 에서 사용 해 야 합 니 다httpbin.bar.포트 80 제외 주의:

대등한 인증 정책 의 포트 값 은 용기 의 포트 입 니 다. TLS의 값 은DestinationRule의 포트 입 니 다.

포트 가Service에 연결 되 었 을 때 만 사용Service합 니 다.그렇지 않 으 면 istio 는 무시 합 니 다portLevelMtls

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "httpbin"
  namespace: "bar"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: STRICT
  portLevelMtls:
    80:
      mode: DISABLE

DestinationRule

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "httpbin"
spec:
  host: httpbin.bar.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    portLevelSettings:
    - port:
        number: 8000
      tls:
        mode: DISABLE

4 정책 우선 순위
네 임 스페이스 범위 보다 대등한 인증 정책 을 지정 합 니 다.정책 을 추가 하면portLevelMtls의Service을 사용 하지 않 습 니 다.예 를 들 어httpbin TLS.네 임 스페이스 범위 의 정책 을 만 들 었 습 니 다.네 임 스페이스foo의 모든 서 비 스 를 사용 하고Service의 요청 을 관찰 합 니 다.
네 임 스페이스 범위 정책

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "foo"
spec:
  mtls:
    mode: STRICT

테스트 명령 실행

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

foo범위 전략

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "overwrite-example"
  namespace: "foo"
spec:
  selector:
    matchLabels:
      app: httpbin
  mtls:
    mode: DISABLE

DestinationRule

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "overwrite-example"
spec:
  host: httpbin.foo.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

테스트 명령 실행

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

다시 실행 TLS요청 을 실행 합 니 다.이번 에는 방문 이 성공 하면 지정 한 서비스의 정책 이 전체 네 임 스페이스 범 위 를 덮어 쓰 는 지 확인 합 니 다.

이 내용에 흥미가 있습니까?

현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:

Kubernetes 환경에서 Datadog Agent의 Istio 오류 이해

Amazon EKS에서 실행 중입니다. 환경 정보나 구축 순서는 이하 페이지와 같습니다. Istio의 도입은 이하를 참고로 했습니다. 모두 오류 내용은 동일합니다. agent.log Agent v7.28.1에 포함된...

텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.

CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.

Istio mtls 사용

좋은 웹페이지 즐겨찾기