Istio Securing (1)

February 13, 2023 교육 v1.0

9장에서는 Istio 에서 제공하는 microservice 환경에서의 Secure 통신에 대해서 다룹니다. 인증을 통해 신원을 확인하고 확인된 신원에 대하여 권한을 확인하는 방법에 대해서 다룹니다

개요

실습 git: https://github.com/istioinaction/book-source-code
출처 : Istio in Action 챕터9

다루는 내용

이미 4장에서 “secure traffic” (트래픽 보안)을 포함하여 “admitting traffic” (트래픽 인가) 에 대해서 다룸
이번 장에서 보다 자세하게 서비스 메시 환경에서 “trasparently improving the security posture” 하는 방법에 대해 다루겠음
Istio 의 보안 메커니즘 - 서비스 간 인증, 유저 인증의 구현, access control - 에 대해 설명

용어•약어

authn - authentication “인증”
authz - authorization “권한”
authentication server - 인증서버
sa - service account
Security posture 보안태세

(generated by you.com) Security posture refers to an organization’s overall cybersecurity strength and how well it can predict [1][2], prevent and respond to ever-changing cyber threats [3]. It encompasses any security measures that are in place, such as firewalls, intrusion detection systems, authentication and authorization protocols, and encryption. Security posture also requires an understanding of the vulnerabilities and risks that come with new technologies and the ability to detect and defend against malicious activity. Good security posture requires an organization to have the right people, processes, and technologies in place to ensure its networks, data, and systems are secure.
SPIFFE, Secure Production Identity Framework For Everyone 동적이고 heterogeneous한 환경에서 identity 를 제공하는 오픈소스 표준
SVID, SPIFFE Verifiable Identity Document - SPIFFE 인증서 (X.509 준수)
mTLS (mutual TLS) - client-server 간 상호 인증 방식
CR, Custom Resource - 쿠버네티스의 사용자 정의 리소스 (명세)
JWT, Json Web Token - a compact claims representation used to authenticate a client to a server
JWKS, **JSON Web Key Set - public key JWT 토큰 검증에 사용
workload - the amount of work that software imposes on the underlying computing resources [2], or the set of components that together deliver business value [3].

실습 환경

minikube (k8s) 및 istio 설치. 참고: https://netpple.github.io/2023/Istio-Environment/
실습 네임스페이스 : istioinaction
실습 디렉토리 : book-source-code

실습 초기화

실습 시 초기화 후 사용하세요

## 실습 네임스페이스 전환 (istioinaction)
kubectl config set-context --current --namespace=istioinaction

## istioinaction
kubectl delete virtualservice,deployment,service,secret,\
destinationrule,gateway,authorizationpolicy,\
peerauthentication -n istioinaction --all

## istio 레이블 제거
kubectl label ns istioinaction istio-injection-

## default namespace
kubectl delete deployment/sleep -n default
kubectl delete service/sleep -n default

## istio-system
kubectl delete authorizationpolicy,peerauthentication \
-n istio-system --all

## istio-proxy 컨테이너 privileged 퍼미션 제거
istioctl install -y --set profile=demo \
     --set values.global.proxy.privileged=false

9.1 The need for application-networking security

Application Security - to protect user data

Authentication and Authorization 리소스 접근에 대한 “인증”과 “권한”
- Authentication - Proof of identity. 클라이언트 혹은 서버의 신원(identity)을 “입증”하는 것 ** ”신원”(identity) 을 알아야 “권한”을 적용할 수 있겠죠*
- Authorization - Process of allowing or denying an already authenticated user. ** 유저의 리소스 요청에 대하여 (인증된) 유저의 권한을 검토하고 접근여부를 결정*
Encryption - 전송 중인 데이터 암호화. 감청 방지

9.1.1 Service-to-service authentication

SPIFFE (Secure Production Identity Framework For Everyone) 모두를 위한 보안제품 인증 프레임웍

보안을 위한 “서비스 간 인증 방법” 이 필요
서비스를 “trust” 할 수 있도록 검증가능한 인증서 제공
인증서는 신뢰할 수 있는 3rd party 발급기관에서 발급하고 검증
Istio 는 SPIFFE 를 사용하여 인증서 발급을 자동화
Istio 는 SPIFFE 인증서를 사용하여 서비스 간에 mutual authentication 을 수행함

9.1.2 End-user authentication

애플리케이션에서 “Private”한 user data 를 저장하고 다루기 위함
end-user authentication 프로토콜 대부분이 “인증 리다이렉팅” 방식을 사용함
유저가 서비스에 요청을 보내면
서비스는 “인증서버”로 유저를 redirecting 함
“인증서버”는 유저 정보를 포함하는 credential (JWT, HTTP Cookie 등) 을 발급함
유저는 발급받은 credential 을 서비스에 제출함
서비스는 유저의 credential 을 “인증서버”에 보내 확인함

9.1.3 Authorization

After authentication

The caller identifies to ther server “who” they are, 호출처가 서버에게 자신이 누구인지를 인증하면
and then the server checks “what” operations this identity is allowed to perform and accordingly admits or rejects it 서버는 호출처의 “identity”로 수행할 수 있는 오퍼레이션이 무엇인지 확인한 다음에 요청을 허용하거나 거절합니다

Istio 는 인증(authentication)과 ID(identity) 모델을 기반으로 서비스 간, 서비스-유저 간에 잘 세분화된(fine-grained) authorization capabilities 를 제공합니다.

9.1.4 Comparison of security in monoliths and microservices

모놀리딕, 마이크로서비스 아키텍처 모두 서비스간, 서비스-유저 간에 “인증과 권한”을 필요로 하는 점은 동일합니다.

하지만 모놀리딕이냐 마이크로서비스냐에 따라 차이가 있습니다.

마이크로서비스
- 커넥션 수 : a lot more interconnections (모놀리딕에 비해서) 커넥션이 많고
- 운영 환경 : utilize dynamic environments such as cloud computing and container orchestration, where services are scheduled into numerous servers and are short-lived 동적인 환경을 필요로 함 (클라우드, 컨테이너 오케스트레이션 등) easily grow into hundreds and thousands of services, which makes operationg services in a static environment untendable 쉽게 수천개, 수백개 서비스로 증가할 수 있기 때문에 정적인 환경에서 운용하기 어려움
모놀리딕
- 커넥션 수 : fewer connections (마이크로서비스에 비해서) 커넥션이 적고
- 운영 환경 : run on more static infrastructure 정적인 환경에서 운용됨 ex) IP is a good source of identity (commonly used in certificates for authentication)

마이크로서비스 환경에서는 전통적인 방법, 예를 들면 static IP 를 identity 수단으로 사용하는 방법 등은 쓰기 어려움

서비스가 수 많은 노드 중 어떤 노드에 배포될 지 모름
심지어 서비스가 서로 다른 네트워크에 포함될 수 있음
서비스가 서로 다른 클라우드나 on-premise 환경에 걸쳐 있을 수 있음

SPIFFE (Secure Production Indentity Framework For Everyone)

이러한 여러 도전적인 문제들을 해결하고, 동적이고 헤테로한 환경에서 identity 를 제공하기 위하여 Istio 는 “SPIFFE” 를 사용합니다
SPIFFE 는 동적/헤테로한 환경에서 identity 를 제공하는 오픈소스 표준 입니다.

9.1.5 How Istio implements SPIFFE

SPIFFE identity - RFC 3986 URI 호환 형식

spiffe://trust-domain/path

trust-domain : 발급자
path : (unique) workload 식별자

The details on how the path identifies the workload are left open-ended and can be decided by the implementer of the SPIFFE specification. path로 workload를 식별하는 방법에 대한 디테일한 부분은 열려 있으며, SPIFFE spec. 구현체에 의해 결정됩니다

Istio populates this path using the service account under which a particular workload runs.

Istio 는 특정 워크로드를 구동하는 서비스 어카운트로 이 path를 채웁니다.

This SPIFFE identity is encoded in an X.509 certificate, also known as a SPIFFE Verifiable Identity Document (SVID), which Istio’s control plane mints for workloads.

SPIFFE identity는 SVID라고도 하며 X.509 인증서로 인코딩됩니다. Istio control plane 에서 워크로드의 SVID를 생성합니다

These certificates are then used to secure the transport for service-to-service communication by encrypting data in transit.

그런 다음 이러한 인증서(SVID)들은 전송 중인 데이터를 암호화하여 서비스 간 통신을 위한 전송을 보호하는데 사용됩니다.

9.1.6 Istio security in a nutshell

To understand Istio security, let’s change to the perspective of the service mesh operator who configures the service proxies using custom resources defined by Istio:

PeerAuthentication : configures the proxy for serivce-to-service authentication. extract peer information for authorization
RequestAuthentication : configures the proxy for end-user authentication. extract user information for authorization
AuthorizationPolicy : configures the proxy for authorizing requests by making decisions based on the data extracted by the PeerAuthentication and RequestAuthentication

스크린샷 2023-02-11 오후 2.05.57.png

9.3 shows how the PeerAuthentication and RequestAuthentication resources configure the proxy to authenticate a request, at which point the data encoded into the credentials (SVID or JWT) is extracted and stored as filter metadata.

AuthorizationPolicy resources decide whether to allow or reject a request based on its connection identity.