Istio를 사용한 마이크로서비스로 돌아갑니다. 3 부

메모. 번역: 첫 번째 부분 이 시리즈는 Istio의 기능을 알아보고 실제로 이를 시연하는 데 전념했습니다. 초 — 세밀하게 조정된 라우팅 및 네트워크 트래픽 관리. 이제 보안에 대해 이야기하겠습니다. 이와 관련된 기본 기능을 보여주기 위해 작성자는 Auth0 ID 서비스를 사용하지만 다른 공급자도 비슷한 방식으로 구성할 수 있습니다.

우리는 Istio의 기능을 시연하기 위해 Istio와 예제 마이크로서비스 애플리케이션인 Sentiment Analysis를 배포한 Kubernetes 클러스터를 설정했습니다.

Istio를 사용하면 재시도, 시간 초과, 회로 차단기, 추적, 모니터링과 같은 레이어를 구현할 필요가 없기 때문에 서비스를 소규모로 유지할 수 있었습니다. 또한 A/B 테스트, 미러링, 카나리아 롤아웃 등 고급 테스트 및 배포 기술을 사용했습니다.

새로운 자료에서는 비즈니스 가치를 향한 길의 마지막 단계인 인증 및 권한 부여를 다룰 것입니다. Istio에서는 정말 기쁩니다!

Istio의 인증 및 승인

나는 인증과 권한 부여에서 영감을 받을 것이라고 결코 믿지 않았습니다. 이러한 주제를 재미있고, 더욱 영감을 주기 위해 Istio는 기술적 관점에서 무엇을 제공할 수 있습니까?

대답은 간단합니다. Istio는 이러한 기능에 대한 책임을 서비스에서 Envoy 프록시로 전환합니다. 요청이 서비스에 도달할 때쯤에는 이미 인증 및 권한이 부여되었으므로 비즈니스에 유용한 코드를 작성하기만 하면 됩니다.

좋은 것 같나요? 내부를 살펴보겠습니다!

Auth0으로 인증

ID 및 액세스 관리를 위한 서버로 평가판이 있고 사용이 직관적이며 마음에 드는 Auth0을 사용하겠습니다. 그러나 동일한 원칙이 다른 경우에도 적용될 수 있습니다. OpenID Connect 구현: KeyCloak, IdentityServer 및 기타 여러 가지.

시작하려면 다음으로 이동하세요. 인증0 포털 귀하의 계정으로 테넌트를 생성하십시오 (테넌트 - "테넌트", 격리의 논리적 단위, 자세한 내용은 다음을 참조하세요. 선적 서류 비치 - 대략. 번역) 그리고 가다 애플리케이션 > 기본 앱고르는 도메인, 아래 스크린샷과 같이:

파일에 이 도메인을 지정하세요. resource-manifests/istio/security/auth-policy.yaml (소스 코드):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

이러한 자원을 바탕으로 Pilot (Istio의 세 가지 기본 제어 평면 구성 요소 중 하나 - 대략 번역) 요청을 서비스로 전달하기 전에 요청을 인증하도록 Envoy를 구성합니다. sa-web-app и sa-feedback. 동시에 서비스 Envoy에는 구성이 적용되지 않습니다. sa-frontend, 프런트엔드를 인증되지 않은 상태로 둘 수 있습니다. 정책을 적용하려면 다음 명령을 실행하십시오.

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

페이지로 돌아가 요청을 하면 다음과 같은 상태로 끝나는 것을 볼 수 있습니다. 무단 401. 이제 Auth0으로 인증하도록 프런트엔드 사용자를 리디렉션하겠습니다.

Auth0으로 요청 인증

최종 사용자 요청을 인증하려면 인증된 서비스(리뷰, 세부 정보 및 평가)를 나타내는 API를 Auth0에 생성해야 합니다. API를 생성하려면 다음으로 이동하세요. Auth0 포털 > API > API 생성 양식을 작성하세요.

여기서 중요한 정보는 확인, 나중에 스크립트에서 사용할 것입니다. 다음과 같이 적어보자:

• 오디언스 (Audience): {YOUR_AUDIENCE}

필요한 나머지 세부 정보는 섹션의 Auth0 포털에 있습니다. 어플리케이션 - 고르다 시험 적용 (API와 함께 자동으로 생성됨)

여기서 우리는 다음과 같이 쓸 것입니다:

• 도메인: {YOUR_DOMAIN}
• 고객 ID: {YOUR_CLIENT_ID}

다음으로 스크롤 시험 적용 텍스트 필드로 허용된 콜백 URL (콜백에 대해 확인된 URL), 인증이 완료된 후 호출이 전송되어야 하는 URL을 지정합니다. 우리의 경우는 다음과 같습니다.

http://{EXTERNAL_IP}/callback

그리고 허용되는 로그아웃 URL (로그아웃이 허용된 URL) 다음을 추가하세요.

http://{EXTERNAL_IP}/logout

프론트엔드로 넘어가겠습니다.

프런트엔드 업데이트

지점으로 전환 auth0 저장소 [istio-mastery]. 이 분기에서는 인증을 위해 사용자를 Auth0으로 리디렉션하고 다른 서비스에 대한 요청에 JWT 토큰을 사용하도록 프런트엔드 코드가 변경되었습니다. 후자는 다음과 같이 구현됩니다(앱.js):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Auth0에서 테넌트 데이터를 사용하도록 프런트엔드를 변경하려면 다음을 엽니다. sa-frontend/src/services/Auth.js 위에서 쓴 값을 그 안에 바꾸십시오 (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

신청서가 준비되었습니다. 변경 사항을 빌드하고 배포할 때 아래 명령에 Docker ID를 지정하세요.

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

앱을 사용해 보세요! 로그인(또는 등록)이 필요한 Auth0으로 리디렉션되며, 그 후 이미 인증된 요청이 이루어지는 페이지로 다시 전송됩니다. 컬을 사용하여 기사의 첫 번째 부분에서 언급한 명령을 시도하면 코드를 얻을 수 있습니다. 401 상태 코드, 요청이 승인되지 않았음을 나타냅니다.

다음 단계인 요청 승인을 진행해 보겠습니다.

Auth0을 통한 승인

인증을 통해 사용자가 누구인지 이해할 수 있지만, 사용자가 액세스할 수 있는 대상을 알기 위해서는 인증이 필요합니다. Istio는 이를 위한 도구도 제공합니다.

예를 들어 두 개의 사용자 그룹을 만들어 보겠습니다(아래 다이어그램 참조).

• 회원 (사용자) — SA-WebApp 및 SA-Frontend 서비스에만 액세스할 수 있습니다.
• 중재자 (사회자) — 세 가지 서비스 모두에 액세스할 수 있습니다.

권한 부여 개념

이러한 그룹을 생성하기 위해 Auth0 Authorization 확장을 사용하고 Istio를 사용하여 다양한 수준의 액세스를 제공합니다.

Auth0 인증 설치 및 구성

Auth0 포털에서 확장 프로그램(확장) 및 설치 인증0 인증. 설치 후 다음으로 이동합니다. 승인 확장, 그리고 오른쪽 상단을 클릭하고 적절한 메뉴 옵션을 선택하여 테넌트 구성으로 이동합니다. (구성). 그룹 활성화 (여러 떼) 규칙 게시 버튼을 클릭하세요. (게시 규칙).

그룹 만들기

인증 확장에서 다음으로 이동하세요. 그룹 그리고 그룹을 만들어요 운영자. 인증된 모든 사용자를 일반 사용자로 취급하므로 해당 사용자를 위해 추가 그룹을 만들 필요가 없습니다.

그룹 선택 운영자, 누르다 회원 추가, 기본 계정을 추가하세요. 일부 사용자는 그룹 없이 그대로 두어 액세스가 거부되도록 하세요. (새 사용자는 다음을 통해 수동으로 생성할 수 있습니다. Auth0 포털 > 사용자 > 사용자 생성.)

액세스 토큰에 그룹 클레임 추가

사용자가 그룹에 추가되었지만 이 정보는 액세스 토큰에도 반영되어야 합니다. OpenID Connect를 준수하고 동시에 필요한 그룹을 반환하려면 토큰에 자체 토큰을 추가해야 합니다. 맞춤 청구. Auth0 규칙을 통해 구현됩니다.

규칙을 만들려면 Auth0 포털로 이동하세요. 규칙, 누르다 규칙 만들기 템플릿에서 빈 규칙을 선택합니다.

아래 코드를 복사하여 새 규칙으로 저장하세요. 그룹 클레임 추가 (네임스페이스그룹.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

주의: 이 코드는 권한 부여 확장에 정의된 첫 번째 사용자 그룹을 가져와 이를 사용자 지정 클레임으로 액세스 토큰에 추가합니다(Auth0에서 요구하는 대로 해당 네임스페이스 아래).

페이지로 돌아가기 규칙 다음 순서로 작성된 두 가지 규칙이 있는지 확인하세요.

• auth0-인증-확장
• 그룹 클레임 추가

그룹 필드는 규칙을 비동기적으로 수신하므로 순서가 중요합니다. auth0-인증-확장 그 후에는 두 번째 규칙에 따라 클레임으로 추가됩니다. 결과는 다음과 같은 액세스 토큰입니다.

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

이제 그룹을 클레임에서 가져올 사용자 액세스를 확인하도록 Envoy 프록시를 구성해야 합니다(https://sa.io/group) 반환된 액세스 토큰에 포함됩니다. 이것이 기사의 다음 섹션의 주제입니다.

Istio의 승인 구성

승인이 작동하려면 Istio용 RBAC를 활성화해야 합니다. 이를 위해 다음 구성을 사용합니다.

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local" 

설명 :

• 1 - 필드에 나열된 서비스 및 네임스페이스에 대해서만 RBAC를 활성화합니다. Inclusion;
• 2 — 우리는 서비스 목록을 나열합니다.

다음 명령을 사용하여 구성을 적용해 보겠습니다.

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created

이제 모든 서비스에는 역할 기반 액세스 제어가 필요합니다. 즉, 모든 서비스에 대한 접근이 금지되며 이에 대한 대응이 이루어지게 됩니다. RBAC: access denied. 이제 승인된 사용자에게 접근을 허용해 보겠습니다.

일반 사용자의 접근 구성

모든 사용자는 SA-Frontend 및 SA-WebApp 서비스에 대한 액세스 권한이 있어야 합니다. 다음 Istio 리소스를 사용하여 구현되었습니다.

• 서비스 역할 — 사용자가 가지고 있는 권리를 결정합니다.
• ServiceRoleBinding — 이 ServiceRole이 누구에게 속하는지 결정합니다.

일반 사용자의 경우 특정 서비스(servicerole.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

그리고 통해 regular-user-binding 모든 페이지 방문자에게 ServiceRole을 적용합니다(일반 사용자 서비스 역할 바인딩.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

"모든 사용자"는 인증되지 않은 사용자도 SA 웹앱에 액세스할 수 있다는 의미입니까? 아니요, 정책은 JWT 토큰의 유효성을 확인합니다.

구성을 적용해 보겠습니다.

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created

중재자를 위한 액세스 구성

중재자의 경우 모든 서비스(모드-서비스-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

그러나 우리는 액세스 토큰에 클레임이 포함된 사용자에게만 그러한 권리를 원합니다. https://sa.io/group 의미를 가지고 Moderators (모드 서비스 역할 바인딩.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

구성을 적용해 보겠습니다.

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created

특사의 캐싱으로 인해 승인 규칙이 적용되는 데 몇 분 정도 걸릴 수 있습니다. 그런 다음 사용자와 중재자의 액세스 수준이 서로 다른지 확인할 수 있습니다.

이 부분에 대한 결론

하지만 인증 및 권한 부여에 대한 더 간단하고 간편하며 확장 가능하고 안전한 접근 방식을 본 적이 있습니까?

서비스에 대한 최종 사용자 액세스의 인증 및 권한 부여를 세밀하게 제어하는 ​​데는 세 가지 Istio 리소스(RbacConfig, ServiceRole 및 ServiceRoleBinding)만 필요했습니다.

또한, 우리는 특사 서비스를 통해 이러한 문제를 처리하여 다음을 달성했습니다.

• 보안 문제 및 버그가 포함될 수 있는 일반 코드의 양을 줄입니다.
• 하나의 엔드포인트가 외부에서 접근 가능하다는 사실이 밝혀지고 이를 보고하는 것을 잊어버리는 어리석은 상황의 수를 줄입니다.
• 새로운 역할이나 권한이 추가될 때마다 모든 서비스를 업데이트할 필요가 없습니다.
• 새로운 서비스는 여전히 단순하고 안전하며 빠릅니다.

출력

Istio를 사용하면 팀은 서비스에 오버헤드를 추가하거나 미시적 상태로 되돌리지 않고도 비즈니스에 중요한 작업에 리소스를 집중할 수 있습니다.

세 부분으로 구성된 이 기사에서는 실제 프로젝트에서 Istio를 시작하기 위한 기본 지식과 미리 준비된 실용적인 지침을 제공했습니다.

번역가의 추신

블로그에서도 읽어보세요.

• "Istio를 사용한 마이크로서비스로 돌아가기": 1부(주요 기능 소개), 파트 2(라우팅, 트래픽 제어);
• «Conduit - Kubernetes용 경량 서비스 메시";
• «서비스 메시란 무엇이며 [마이크로서비스가 포함된 클라우드 애플리케이션의 경우] 서비스 메시가 필요한 이유는 무엇입니까?".

출처 : habr.com