1. 개요

- 프록시를 사용하여 서비스 또는 마이크로서비스 간의 서비스 간 통신을 용이하게 하기 위한 전용 인프라 계층

- 애플리케이션 트래픽을 관리, 추적 및 보안성을 강화하기 위해 플랫폼 레이어에 구성되는 네트워크 제어 방법

 

2. 마이크로 서비스와 서비스 매쉬

2.1 프록시

MSA 구조의 경우 수 백, 수 천개 이상의 서비스가 존재 할 수있으며, 서비스 → 서비스 호출 시 장애 전파 현상으로 원인을 찾기가 어려움. B Service에 장애가 날 경우, A Service에서도 응답을 제대로 받지 못해 장애가 전파 됨.

서비스 앞에 프록시를 이용하여 트래픽을 네트워크 단에서 통제 할 수 있다. 프록시에서 메시지 헤더를 보고 원하는 대상으로 라우팅(지능형 라우팅)을 할 수 있다.

ex. Client 필드가 Android이면, 안드로이드 서비스로 라우팅

 

 

 

 

서비스 수에 따라 프록시 수도 증가하기 때문에 프록시 설정이 어려워지며, 설정 정보를 중앙 집중화된 컨트롤러가 통제하는 구조를 취할 수 있다.

 

 

 

출처) https://bcho.tistory.com/1293

 

3. 서비스매시 솔루션

3.1 istio vs linkerd

  • 서비스 매시를 구현하기 위해서는 사이드카 프록시가 필요하다.
  • istio 등장으로 서비스 매시 개념이 전파되었으며, 유연하고 범용적인 프록시인 엔보이를 사용한다. 엔보이는 인그레스, 이그레스, 서비스메시 사이트가 등 다양한 방법으로 사용할 가능하여 보다 복잡하고 사용이 까다롭다.
  • linkerd 에서는 linkerd2-proxy라는 프록시를 사용하며, 엔보이보다 가볍고 사용하기 쉽다.
  • 엔보이는 오버플로우에 취약한 C++로 작성되었으며, linkerd2-proxy는  메모리 안전성이 특징인 Rush로 작성되어 보안적으로 유리할 것이라고 한다.
  • linkerd가 istio 보다 리소스 사용량이 훨씬 적으며, 네트워크 지연도 적게 발생.
  • 아래 글을 보면 아키텍처 및 태생 언어에 대한 이유로  istio에 비해 linkerd가 더 작고 빠르고 보안에 뛰어나다고 한다.

 

 

4. Linkerd(링커디) 설치 및 사용법

4.1 Install the CLI

curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh

# Add the linkerd CLI to your path
export PATH=$PATH:/root/.linkerd2/bin

# linkerd version
Client version: stable-2.13.5
Server version: unavailable

4.2 Validate your Kubernetes cluster

root@edu03-master1:~# linkerd check --pre
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

kubernetes-version
------------------
√ is running the minimum Kubernetes API version

pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create non-namespaced resources
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create CronJobs
√ can create ConfigMaps
√ can create Secrets
√ can read Secrets
√ can read extension-apiserver-authentication configmap
√ no clock skew detected

linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date

Status check results are √

4.3 Install Linkerd onto your cluster

linkerd install --crds | kubectl apply -f -

linkerd install | kubectl apply -f -
root@edu03-master1:~# kubectl -n linkerd get pod
NAME                                      READY   STATUS    RESTARTS   AGE
linkerd-destination-8554fb9f7f-gglc7      4/4     Running   0          84s
linkerd-identity-8476c4dd4-grpfl          2/2     Running   0          85s
linkerd-proxy-injector-66875b9fd6-fpvqh   2/2     Running   0          84s


linkerd check

4.4 Install the demo app

(1) Emojivoto 데모 애플리케이션 설치

 - Emojivoto is a simple standalone Kubernetes application that uses a mix of gRPC and HTTP calls to allow the user to vote on their favorite emojis.

 - Install Emojivoto into the emojivoto namespace by running:

$ curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/emojivoto.yml \
  | kubectl apply -f -
  
  
$ kubectl -n emojivoto edit svc web-svc
  Change ServiceType : ClusterIP -> NodePort 
  
  
$ kubectl -n emojivoto get svc | grep web-svc
web-svc      NodePort    10.233.4.174            80:31873/TCP        5m13s

 

(2) 브라우저 접속 - http://192.168.110.31:31873/

 

(3) 도넛 이모지에 투표 할 경우, 404 에러 발생

 
 

(4) linkerd inject 수행

  • linkerd-proxy라는 이름의 사이트카 프록시 컨테이너 생성
  • inject 해도 서비스에 변경은 없으며, 사이드카 컨테이너가 추가 된 것을 볼 수 있다.
kubectl get -n emojivoto deploy -o yaml \
  | linkerd inject - \
  | kubectl apply -f -

 

 

 

 

4.5 linkerd 로 문제 파악하기

(1) 대시보드(viz extension) 설치

$ linkerd viz install | kubectl apply -f -


$ kubectl -n linkerd-viz get pod
NAME                           READY   STATUS    RESTARTS   AGE
metrics-api-6d69f7fbfb-vzmv2   2/2     Running   0          56s
prometheus-7ddcdc4b5c-wchs8    2/2     Running   0          55s
tap-55c8f8b67b-8nmvl           2/2     Running   0          55s
tap-injector-55ddf4746-brsjt   2/2     Running   0          53s
web-6fd5fdf594-xxjzz           2/2     Running   0          54s


$ linkerd check


$ kubectl -n linkerd-viz edit svc web
  Change ServiceType - ClusterIP to NodePort

 

 

(2) ingress 설정

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: web-ingress-auth
  namespace: linkerd-viz
data:
  auth: YWRtaW46JGFwcjEkbjdDdTZnSGwkRTQ3b2dmN0NPOE5SWWpFakJPa1dNLgoK
---
# apiVersion: networking.k8s.io/v1beta1 # for k8s < v1.19
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: linkerd-viz
  annotations:
    nginx.ingress.kubernetes.io/upstream-vhost: $service_name.$namespace.svc.cluster.local:8084
    nginx.ingress.kubernetes.io/configuration-snippet: |
      proxy_set_header Origin "";
      proxy_hide_header l5d-remote-ip;
      proxy_hide_header l5d-server-id;      
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: web-ingress-auth
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required'
spec:
  ingressClassName: nginx
  rules:
  - host: dashboard.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web
            port:
              number: 8084
kubectl apply -f viz-ingress.yml

root@edu03-master1:~# kubectl -n ingress-nginx get svc
NAME                                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             NodePort    10.233.27.166   <none>        80:32235/TCP,443:30030/TCP   7m17s
ingress-nginx-controller-admission   ClusterIP   10.233.19.173   <none>        443/TCP                      7m17s

 

(3) 브라우저 접속 - https://dashboard.example.com:30030/

  • hosts 파일 수정
  • protects it with basic auth using admin/admin

 

 

(4) 도넛 이모지에 투표하면(404에러 발생 시) SR(Success Rate)가 내려가는 것을 볼 수 있음.

  • deploy/emoji SR 100%이고, deploy/voting 이 100%가 아니기 때문에, deploy/web에서 voting 기능 일부 요청이 실패한 것으로 추측할 수 있다.
  • 의존성이 있는 deploy 요청 실패는 웹이 반환하는 오류의 원인 일 수 있다.
 
 

(5) 위 캡처 중 [LIVE CALLS] 항목이 나오지 않은 이유는 linkerd 설치 후 서비스 파드가 재기동 되지 않았기 때문이며, 서비스 파드 재기동 후 아래와 같이 Path가 보인다.

  • [LIVE CALLS] 내용 중 호출 된 URL을 보면 deploy/voting 서비스로 POST 메서드로 /emojivoto.v1.VotingService/VoteDoughnut 패스를 요청하는 부분에서 Success Rate가 0인 것을 확인 할 수 있다.

 

 

 

 

참고) https://github.com/linkerd/linkerd2

 

 

 

 

 

'DevOps' 카테고리의 다른 글

Harbor_Registry  (1) 2022.12.28
소프트웨어 스택  (0) 2022.11.08
[GateKeeper] K8s 정책제어  (0) 2022.10.13
[DevOps] ArgoCD 구축/테스트  (0) 2022.10.11

1. Harbor 란?

쿠버네티스 환경에서는 이미지를 저장할 수 있는 레지스트리가 필요하며, 역할 기반 접근제어(RBAC), 이미지 서명, 이미지 취약성 스캐닝 등의 기능이 있는 오픈소스 레지스트리인 Harbor가 하나의 선택지로 좋은듯하다.

 

1.1. Registry란?

쿠버네티스, DevOps, 컨테이너 기반 개발을 위한 이미지를 저장되는데 사용되는 Repository이다. 퍼블릭 레지스트리에서 사용자가 원하는 이미지를 다운로드 받을 수도 있지만, 개인이나 조직에서 프라이빗 레지스트리를 구축하여 사용할 수도 있다.

 

1.2. Harbor 특징

오픈 소스

Harbor는 CNCF에서 관리되는 오픈소스로서, 컨테이너 이미지를 저장할 수 있는 프라이빗 저장소로 사용 가능하다.

간편한 설치

설치 및 적용이 간편하고, UI도 직관적이다.

 

1.3. Harbor의 구조

Harbor는 스토리지나 데이터베이스에 데이터를 저장하며, harbor-helm 차트를 이용하여 설치하면 기본으로 postgresql 데이터베이스를 설치한다. 사용자는 프로젝트를 통해 정책과 롤 기반으로 접근을 제어(RBAC)할 수 있으며, 이미지 저장, 이미지 보안 취약성 검사, 보안, UI 등 사용자가 레지스트리 솔루션을 편리하게 사용할 수 있는 최소한의 기능들을 제공하여 구조가 복잡하지 않다.

 

 

2. Harbor 사용 

2.1. Cloud Native Registry

(1) Harbor GUI 페이지 접속

(2) Harbor 로그인

(3) [Projects] - [NEW PROJECT]로 프로젝트 생성

(4) [Project Name] 설정. 필요 시 [Storage Quota] 설정

(5) 생성 된 [first-project] 클릭

(6) [PUSH COMMAND] 누르면 예제 명령어 확인 가능

(7) 클라이언트에서 nginx 이미지 업로드

(8) first-project에서 업로드 된 이미지 확인

 

2.2. User 생성 및 할당

(1) User 생성.

  • Local DB의 경우 [Users] 탭에서 생성
  • OIDC 연동된 경우에는 해당 솔루션(Keycloak)에서 유저 생성

 

(2) 신규 유저 할당 할 프로젝트로 이동

 

(3) [members] 탭에서 User 추가 및 Role 할당

  • Project Admin : 읽기, 쓰기, 구성원 추가 및 제거, 취약성 스캔
  • Maintainer : 이미지 스캔, 복제 작업 보기, 이미지 및 Helm 차트 삭제
  • Developer : 프로젝트에 대한 읽기 및 쓰기 권한
  • Guest : 읽기 전용 권한, 이미지 pull 및 tag 설정은 가능하지만 push는 불가능
  • Limited Guest : 이미지 pull 만 가능. 이미지 push 및 로그, 다른 멤버는 볼 수 없음

 

(4) developer 계정 추가 확인

 

(5) developer로 로그인 시 Role에 맞는 권한으로 화면이 보여짐

 
 

2.3. 이미지 취약점 스캐닝(trivy)

(1) 이미지 취약점 스캔이 필요한 이미지가 있는 프로젝트로 이동

(2) 스캔 할 이미지를 선택

(3) Artifacts 선택 후 [SCAN] 클릭

(4) 스캔이 끝나면 취약점 리스트 상세 보기로 결과 확인

 
 

2.4. 이미지 서명(Cosign)

 인터넷에서 다운 받은 이미지에 어떤 코드가 반영되어있는지 확인하기가 어렵고, 어떤 소프트웨어가 설치되어있는지 확인하기가 어렵기 때문에 확인되지 않은 이미지로 시스템을 구축하면 공격의 대상이 될 수 있다. 공식 origin 이미지를 사용하여 생성된 이미지에 Signer를 통해 서명하고 서명된 이미지만으로 시스템을 구축/업그레이드하여 관리가 필요하다.

 TUF(The Update Framework)는 저장소나 서명 키를 손상 시키는 공격자로부터 시스템을 보호하는 프레임워크를 일컬으며, Harbor 프로젝트 v2.5.0까지는 TUF를 구현한 오픈소스 프레임워크인 Notary를 사용하여 이미지 서명 기능을 제공하고 있다. 하지만, Notary의 복잡성 및 프로젝트가 활발히 진행되지 않기 때문에 Harbor v2.6.0~v2.8.0에서 Deprecate 되기로 결정되었다. 그 대신 OCI artifact 서명 및 확인 솔루션인 Cosign을 이용한 서명을 사용하도록 권장하고 있다.

 

(1) Cosign 설치

# Ubuntu
wget "https://github.com/sigstore/cosign/releases/download/v1.6.0/cosign_1.6.0_amd64.deb"
dpkg -i cosign_1.6.0_amd64.deb

*환경 별 설치 방법 참고 https://docs.sigstore.dev/cosign/installation

 

(2) Local Keypair 생성

root@master01:/harbor/cosign# cosign generate-key-pair
Enter password for private key:
Enter password for private key again:
Private key written to cosign.key
Public key written to cosign.pub

root@master01:/harbor/cosign# ls -l
total 20
drwxr-xr-x  2 root root 4096 Dec 14 14:16 ./
drwxrwxrwt 13 root root 4096 Dec 14 14:16 ../
-rw-------  1 root root  649 Dec 14 14:16 cosign.key
-rw-r--r--  1 root root  178 Dec 14 14:16 cosign.pub

 

(3) 이미지 서명

  • 이미지 서명은 로컬 위치한 이미지에는 수행 할 수 없다. Registry에 push 후 수행하여야 한다.
root@master01:/harbor/cosign# cosign sign --key cosign.key harbor.k8s.test/first-project/nginx:1.19
Enter password for private key:
Pushing signature to: harbor.k8s.test/first-project/nginx

 

(4) 이미지 서명 확인

  • Harbor에서 업로드 된 이미지를 선택하여 [Signed by Cosign] 항목 확인
 

참고사이트

https://goharbor.io/docs/2.5.0/

https://github.com/sigstore/cosign

https://github.com/goharbor/harbor/releases


'DevOps' 카테고리의 다른 글

Service Mesh - Linkerd  (0) 2023.07.14
소프트웨어 스택  (0) 2022.11.08
[GateKeeper] K8s 정책제어  (0) 2022.10.13
[DevOps] ArgoCD 구축/테스트  (0) 2022.10.11

DevOps는 문화 또는 방법론이기 때문에 정답이 없으며, 개발과 운영에 대한 모든 솔루션을 잘 엮어서 사용하기 편리하도록 CI/CD 파이프라인 및 프로세스를 정립해야 합니다.

 

DevOps 구성요소

- 문서관리

- 프로세스 관리

- 개발관리

- 계정관리

- 형상관리

- 품질관리

- 배포관리

- 커뮤니케이션

 

 

 

Kubernetes 기반 DevOps 구축을 위한 기본 소프트웨어 스택으로 외부 솔루션(Confluence, Jira, Slack 등) 과 연동하여 완전한 DevOps 시스템을 구축합니다.

 

 

'DevOps' 카테고리의 다른 글

Service Mesh - Linkerd  (0) 2023.07.14
Harbor_Registry  (1) 2022.12.28
[GateKeeper] K8s 정책제어  (0) 2022.10.13
[DevOps] ArgoCD 구축/테스트  (0) 2022.10.11

OPA란?

 - Open Policy Agent의 약어

 - OPA는 플랫폼 관리자에게 세밀한 권한 관리를 할 수 있도록 지원하는 범용 정책 엔진으로 K8S 뿐 아니라 OPA 엔진을 이용하는 모든 플랫폼에서 사용 가능

 

 

(1) OPA 동작

 - 요청이 들어오면 서비스는 JSON을 이용하여 OPA에 허용 여부 질의
 - 질의를 받은 OPA는 저장된 Policy를 불러와서 요청에 대한 평가를 하고 결과를 다시 JSON 형식으로 서비스에 반환

 

(2) 정책 설정

 - OPA는 Policy를 기반으로하여 사용자 접근을 관리하기 때문에 Policy를 어떻게 작성하는지가 중요함
 - Policy는 Rego라는 자체 질의언어를 이용하여 작성해야 하며, Rego 언어가 선언적으로 동작하기 때문에 해당 문법에 대한 이해 필요

 

 

 

Gatekeeper 란?

 - 게이트키퍼는 내부적으로 OPA 엔진을 사용하는 OPA의 K8S 승인/제어를 위해 제작된 솔루션

(1) Gatekeeper 동작

 - K8S에서는 정책적인 결정을 API 서버와 분리하여 독립적으로 할 수 있게 Admission Controller Webhook (이하 웹훅) 제공
 - 웹훅은 클러스터가 변경될 때 무조건 실행되며, 게이트키퍼는 웹훅을 확인하여 OPA 정책 엔진에서 정의한 대로 실행

 

(2) 주요 기능

 Validating Admission Control
  - 웹훅을 트릭거로 OPA와 api-server 다리 역할을 하여 정책 적용
Policies and Constraints
  - Rego 언어로 작성되며 정의한 요구하상을 위반하는 리소스들을 확인
Audit
  - 배포된 자원을 정기적으로 감사하여 Constraints에 반하는 것이 있는지 확인
Data Replication
  - 리소스를 복제 한 후 감사가 진행되며, 복제할 수 있도록 권한 부여 필요

 

 

(3) Gatekeeper Library

 - 게이트키퍼에서는 K8S에서 일반적으로 사용하는 정책에 대한 샘플 제공

탬플릿 설명
allowedrepos 허용된 이미지 Repository만 사용하도록 설정
block-endpoint-edit-default-role endpoint 편집 불가능하도록 설정(CVE-2021-25740)
block-nodeport-services NodePort 서비스 불가능하도록 설정
containerlimit 컨테이너의 리소스 제한 (CPU, Memory)
containerresourceratios 컨테이너 리소스 사용률 제한
disallowdtags 사용할 수 없는 image 태그 지정
externalip 허용 리스트에 포함되지 않은 external IP 제한
httpsonly 인그레스가 https만 사용하도록 설정
imagedigests 컨테이너 이미지에 digest를 확인 (이미지에 대한 유니크확인)
replicalimits deployment에서 pod에 대한 min/max 값 제한
requiredannotations 모든 리소스에 대해 지정된 정규표현식에 맞는 Annotation을 포함하도록
requiredlabels 모든 리소스에 대해 지정된 정규표현식에 맞는 Label을 포함하도록
requiredprobes 파드에 readiness probe, lineness probe가 있어야
uniqueingresshost 모든 인그레스의 host가 유니크해야
uniqueserviceselector 네임스페이스 내의 serviceselector 가 유니크해야

 

 

 

- Pod Security Policy의 설정을 게이트키퍼에서 제약조건 및 탬플릿을 배포하여 정책 설정 가능

Control Aspect Field Names in PSP Gatekeeper Constraint and Constraint Template
Running of privileged containers privileged privileged-containers
Usage of host namespaces hostPID, hostIPC host-namespaces
Usage of host networking and ports hostNetwork, hostPorts host-network-ports
Usage of volume types volumes volumes
Usage of the host filesystem allowedHostPaths host-filesystem
White list of Flexvolume drivers allowedFlexVolumes flexvolume-drivers
Requiring the use of a read only root file system readOnlyRootFilesystem read-only-root-filesystem
The user and group IDs of the container runAsUser, runAsGroup, supplementalGroups, fsgroup users*
Restricting escalation to root privileges allowPrivilegeEscalation, defaultAllowPrivilegeEscalation allow-privilege-escalation
Linux capabilities defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities capabilities
The SELinux context of the container seLinux seLinux
The Allowed Proc Mount types for the container allowedProcMountTypes proc-mount
The AppArmor profile used by containers annotations apparmor
The seccomp profile used by containers annotations seccomp
The sysctl profile used by containers forbiddenSysctls,allowedUnsafeSysctls forbidden-sysctls

 

(4) Gatekeeper Library 샘플 구조

 - OPA 정책에 대한 탬플릿 파일과 제약사항 정의파일 및 예제파일로 구성

 

(5) Gatekeeper Library 샘플

[allowedrepos]
 - 허용된 이미지 repositor만 사용하도록 설정

 

 

 

 

참고)

https://github.com/open-policy-agent/gatekeeper

 

 

 

 

 

'DevOps' 카테고리의 다른 글

Service Mesh - Linkerd  (0) 2023.07.14
Harbor_Registry  (1) 2022.12.28
소프트웨어 스택  (0) 2022.11.08
[DevOps] ArgoCD 구축/테스트  (0) 2022.10.11

Kubernetes에 ArgoCD 배포

환경

root@k8s-master01:~# kubectl get nodes
NAME           STATUS   ROLES                  AGE   VERSION
k8s-master01   Ready    control-plane,master   26d   v1.20.7
k8s-master02   Ready    control-plane,master   26d   v1.20.7
k8s-master03   Ready    control-plane,master   26d   v1.20.7
k8s-worker01   Ready    <none>                 26d   v1.20.7
k8s-worker02   Ready    <none>                 19d   v1.20.7

ArgoCD 배포

  • argocd 네임스페이스 생성
kubectl create namespace argocd
  • argocd 배포
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

ArgoCD 접근

  • Web 접근을 위해 svc 타입 변경
kubectl -n argocd edit svc argocd-server
 ClusterIP -> NodePort
  • Web Passwd 확인
root@k8s-master01:~# kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

C4MDJqQaXZT1Kd3K

 

ArgoCD - GitHub 연동

  • 설정 - Repositories - [CONNECT REPO USING HTTPS] - github 정보입력

  • 연결 확인

ArgoCD - 애플리케이션 배포

  • ArgoCD - Applications 탭 - [NEW APP] 생성

 

 

 

 

  • App 상태확인

ArgoCD 테스트

  • deployment 확인

  • deployment 삭제

  • Sync 확인

'DevOps' 카테고리의 다른 글

Service Mesh - Linkerd  (0) 2023.07.14
Harbor_Registry  (1) 2022.12.28
소프트웨어 스택  (0) 2022.11.08
[GateKeeper] K8s 정책제어  (0) 2022.10.13

+ Recent posts