SK shieldus Rookies 16기 (클라우드 보안 컨설팅 실무 #03)

만두다섯개·2024년 1월 19일
0

SK 루키즈 16기

목록 보기
50/59

주요 정보

  • 교육 과정명 : 클라우드기반 스마트융합보안 과정 16기
  • 교육 회차 정보 : '24. 01. 19. 클라우드 보안 컨설팅 실무 #03

학습 요약

  • 취약점 분석평가(CCE)에 대해 개별적으로 배워야 한다. 회사에서는 기술적 내용만 알려줄 것이다.

3. 클라우드컴퓨팅서비스 프레임워크 및 기술(계속)

Hypervisor

하드웨어를 가상화하기 위해 하드웨어를 관장할 뿐 아니라 각각의 가상머신들을 관리할 가상머신모니터(VMM)과 같은 중간관리자가 필요하며, 이를 하이퍼바이저라고 한다.
하이퍼바이저는 VM이 동작할 수 있는 환경을 제공한다.

VM(==Virtual Server, VS)
컴퓨터 에뮬레이션으로, 프로그램을 실제 컴퓨터처럼 실행한다. 하이퍼바이저를 통해 물리적 기계 위에서 실행된다.

하이퍼바이저는 IaaS 프로비저닝 하는 응용 및 보안 영역이다.
유일 CASE는 CSP가 취약점 분석을 외주맡기는 사례 존재.
IaaS제공 CSP은 하이퍼바이저 취약점 진단하는 경우는 드물다.
Private Cloud가능하다.

하이퍼바이저 종류

Tpye 1 Bare-metal 기반 : 하이퍼바이저가 하드웨어 바로 위에서 실행되는 방식이다. 하이퍼바이저가 하드웨어를 직접 제어하기 때문에 효율적인 자원 사용, 별도의 Host OS가 없으므로 오버헤드가 적지만, 여러 하드웨어 드라이버를 세팅해야 하므로 설치가 어렵다.

Type 2 Host 기반 : 하드웨어 위 Host OS가 존재하고, 그 위에서 하이퍼바이저가 다른 응용프로그램과 유사한 형태로 동작. 기존 컴퓨터 환경에서 하이퍼바이저를 활용하는 것이기에 설치가 용이하고 구성이 편리한 장점이 있다. Type 1 보다는 성능이 떨어진다.

가상화와 클라우드컴퓨팅 비교

  1. 가상화
  • 기존 물리적 서버를 추상화 (싱글 테넌트), CAPEX 높음
  • 이미지 기반(어플리케이션, OS, 등)
  • 부대설비, 전력설비 등을 구축으로 많은 CAPEX(초기자본) 필요, 그러나 낮은 OPEX
  1. 클라우드컴퓨팅
  • 주문형
  • 템플릿 기반(아마존 리눅스, 우분트, 등)
  • 비용 처리 체계(CSC, CSU 필요한 IaaS~SaaS 선택)
  • 퍼블릭 클라우드 사용 시, 낮은 CAPEX와 높은 OPEX(발생 시, 사용한 만큼 지불)
  • 다수의 가상화를 통한 추상화 가능

CAPEX란? 자본 지출, 미래의 이윤 창출 목적으로 지출된 투자 과정의 비용(설비투자비용 등)
OPEX란? 운영 비용, 갖춰진 설비를 운영하는데 드는 제반 비용

클라우드 컴퓨팅 인스턴스

  1. 인스턴스
  • 서버 리소스
  • CSP는 데이터 센터에서 H/W를 유지 관리하고 인스턴스 형태로 컴퓨팅 리소스에 대한 가상 리소스 접근을 제공한다
  • 컨테이너, DB, 마이크로서비스, 가상 머신 등의 컴퓨팅 집약적 워크로드 실행 가능
  1. 인스턴스 특징
    가. 확장성 : 워크로드 요구사항에 따라 인스턴스 컴퓨팅 리소스를 조정. 개발자는 CPU, 메모리, 스토리지 및 네트워크 리소스를 인스턴스로 늘려 클라우드 리소스를 수평적으로 조정 가능
    나. 내결함성 : 조직에서는 백업 목적으로 중복 인스턴스를 사용(중복성)한다. 이는 데이터 처리와 같은 메모리 집약적 워크로드 관리 시 유용하다. 유럽에서 호스팅 되는 클라우드 인스턴스에 장애가 발생하더라도 애플리케이션은 미국과 아시아의 다른 인스턴스에서 계속 실행될 수 있다.

  1. AWS 인스턴스 종류
  • General Purpose Instances(범용 목적 인스턴스)
    * CPU, 메모리, 스토리지 IN/OUTPUT 속도가 평균 사용 (T2, M4, ... 코드화)

  • Compute Optimized Instances(컴퓨팅 최적화 인스턴스)
    * CPU 처리속도 중점(데이터분석, 빠른 처리 속도 요구 어플리케이션)

  • Memory-Optimized Instances(메모리 최적화 인스턴스)
    * 메모리 최적화 인스턴스 (CPU, 스토리지보다 뛰어나다) 사용으로 DB(관계, 비관계형)에 주로 사용

  • Accelerated Computing Instances(가속화된 컴퓨팅 인스턴스)
    * 그래픽 처리(동적, 정적 처리), 비디오 스트리밍 서비스, 애니메이션 어플리케이션 등

  • Storage Optimized Instances(스토리지 최적화 인스턴스)
    * IOPS 관점을 둔 인스턴스로, 증권업체, 빅데이터 기반 분석처리, 스토리지 대용량 사용 및 높은 IOPS 필요에 최적화된 인스턴스.

IaaS에서의 가상 서버 VS 컨테이너 아키텍처

  1. IaaS에서의 가상 서버

vs1, vs2, vs3 , ...
가상 서버(VM == VS)
하이퍼바이저
OS (물리적)
호스트 서버
하드웨어
물리적 페실리티

  1. 컨테이너 아키텍처

빨간색이 차이점 (가상 서버 하이퍼바이저), 컨테이너( 컨테이너 엔진, 커널)

컨테이너 장점

  • 응용프로그램 동작환경 : 애플리케이션 레벨 고립
  • 환경 구축 시간이 하이퍼바이저 기반 VM보다 빠른 셋업
  • 메모리 사용 : 하이퍼바이저 기반 VM보다 메모리 덜 소모
  • 응용프로그램 마이그레이션 및 전송 속도 : 마이그레이션, 백업, 전송 쉬움,VM 비에 크기가 작다.
  • 성능 : 하드웨어와 빠른 커뮤니케이션에 따라 성능 효과적
  • 응용 프로그램 배치 및 유지보수 향상 효과
  • 데이터 전달 속도 : 애플리케이션 전달 시간 감소

컨테이너 종류

클라우드 보안컨설팅 주력 대상. PaaS 기반 솔루션 사용 중. (볼드체는 국내 주력 벤더)
1. Docker
2. Kubernetes

3. AWS fARGATE (Serverless)
4. Google Kubernetes Engine(GKE)
5. Amazon ECS/ECR/EKS
6. Core OS Container Linux
7. Microsoft Azure Container((AKS)
8. NCP Ncloud Kubernetes Service)
9. NHN - Nhn kubernetes Service(NKS)

10. COCKTAIL cloud : 나무기술

쿠버네티스 개념

보안컨설팅, CSC 컨테이너 아키텍처 개념 이해 어려움.

  • Orchestration : 서비스 제공 목적으로 각 애플리케이션의 기능 통합하는 기술.
  • 관리 기능 : 컨테이너 스케줄링, 확장 및 축소 기능
  • 쿠버네티스 구축환경 요건 : 종합적 컨테이너 인프라 제공 목적으로 네트워킹, 스토리지, 보안, 텔레메트리, 기타 서비스를 통합해야 한다.
  • 애플리케이션 리소스 관리 기능 : 배포 및 업데이트 제어하고 자동화 한다. (버그, 보안 패치)

쿠버네티스에서 제공하는 기능
컨테이너 운영 목적의 기능 : 네트워킹, 스토리지, 보안, 텔레메트리, 기타 서비스, 등..

쿠버네티스 아키텍처

3(+1)개 아키텍처
User interface, Master Node, Worker node, ?? 로 구성

1. User interface

UI : CSU 사용, 쿠버네티스 클라우드 콘솔이라고도 한다.
CLI(KubeCLI) : kubelet이 선 실행되어야 실행 가능.

2. Master Node

  • Control plane

  • Kube API Server

  • Scheduler

  • Contorller-Manager
    node 컨트롤러
    work 컨트롤러
    endpoint endpointslice 컨트롤러
    서비스 계정 컨트롤러 : 쿠버네티스도 OS으로 사용자 계정 생성, 변경, 삭제 권한처리 담당 컨트롤러

  • eted : 컴퓨터 임시 저장소

    3. Work node

    컴퓨터 하나의 체계를 Work node라고 한다.
    kublet 1개당 worker node 1개 지정.

  • Pod : 컨테이너를 논리적으로 그룹화 시킨 것. 컨테이너는 하나의 애플리케이션(응용 프로그램, 컴퓨터)로써 동작한다. SaaS 기반에서는 하나의 테넌트가 된다. pod 간 통신을 위해 별도의 라우팅 설정을 지정해주어야 한다.

  • kubernetes runtime : kublet 실행 시, 메모리에 kubernetes runtime 적재된다. DevOps로 pod 생성.

  • kubelet : k8s 실행을 위한 데몬(agent)

  • kube-proxy : 네트워크 담당. 라우팅 테이블 설정 및 송/수신지 IP설정.

아키텍처 설계 단계에서 컨테이너 이중화 구성과 같이 Well-Architected Framework에 입각해 안전성(Reliability)을 고려해야 한다.

Persistent Storage & Container Registry

도커 이미지 저장소

Docker 구성 및 개념

Docker 일반적 아키텍처는 아래와 같다.
k8s의 부분과 개념이 유사하지만, 지정 단어가 다르므로 이를 구분해 사용해야 한다.

Client

k8s의 User Interface 부분

Docker Host

k8s의 worker node 부분
k8s의 containers는 pod 부분이다.

Resigsry

Docker Engine Architecture 및 동작구조

Docker 구성요소

  • Docker API : TCP 소켓을 이용해 Docker Engine에 명령어를 이용해 Docker 제어 인터페이스
  • Docker CLI : Docker Engine에게 사용하는 명령어
  • Distrubution : 사설 Docker 이미지 저장소. 이미지 저장, 배포 기능
  • Orchestration : 컨테이너 오케스트레이션은 개별 구성 요소와 애플리케이션 계층의 작업 정리 과정 의미.
  • Volumes : 도커 컨테이너에서 도커 내부에 도커 엔진 관리하는 볼륨 생성. 생성된 볼륨은 /var/lib/docker/volumes 경로 저장, docker 사용해 관리.
  • Containerd : 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 모든 것들을 포함하는 파일 시스템
  • Docker Build(BuildKit) : 도커 이미지 빌드시 사용하는 용어.
  • Networking : Docker 애플리케이션 컨테이너 안에서 실행된다. 컨테이너 간 연결, 기존 네트워크와 Vlan 연결 지원.

가상화 VS 도커(컨테이너)

컨테이너 보안

컨테이너 보안 이슈에대해 기술한다.

  1. 컨테이너 애플리케이션 접근 제어
    컨테이너에서 애플리케이션 실행 시, ACL을 사용해 접근통제를 수행한다.
    이때, Access List를 사용해 직무 목적에 따라 접근권한을 부여한다.

  2. 컨테이너 이미지 보안
    검증되지 않은 Registery 솔루션 사용 금지. nginx, AWS ECR, K8S Resgister 사용해야 한다. 이는 기술지원 및 보안패치도 지원한다.

Q. 검증된 레지스트리 솔루션은 오픈소스가 아닌 CSP 같은 곳에서 제공하는 레지스트리 솔루션을 지향 하라는 말씀이신가요?
A. 개인용 관점에서는 무료 레지스트리 사용 무방하다. 그러나 업무 목적에서는 상용화된(보통 가격이 저렴한 레지스트리 포함) 것 들 중, CSP 제공 레지스트리 지향하라.
별도의 외부 감사, 클라우드 인증이 이루어지지 않는다. 이는 위협에 노출된다는 의미이다.

클라우드 점검 가이드

KISA에서 제공하는 CCE 취약점에 대한 기술적 보안가이드이다.
클라우드 취약점 점검 가이드
K8S에 대한 점검은 특정 사이트(안전상의 이유로 표기 안 함)에서 확인 가능하다. 해당 가이드라인을 보고 취약점 진단 스크립트 작성 혹은 체크리스트를 만들어 취약점 진단을 해야 한다.

불필요 이미지 종속성 사용 제거
1) 호스트 Volume 내 데이터 읽기 제한 설정
2) 파일 시스템으로부터 읽기 제한 설정
3) Kubelet 등 구성설정 읽기 제한. 관리자 권한 부여자만 접근

  1. 루트 권한으로 이용하는 컨테이너 동작
    지정된 서비스 사용자 계정으로(Root 금지) 컨테이너 Image 생성한다.
    컨테이너 서비스는 Root 권한을 제거한다.

  2. 사용자 권한
    제한된 권한 유지 설정
    Pod view 및 List 권한 제한
    컨테이너 응용프로그램 업무 목적에 따른 RBAC 적용
    컨테이너 응용프로그램에 대한 사용권한 설정
    Pod 간 데이터 통신 규칙 정의 (조직 단위별_OU 별 Pod 구분시 체계적 분류가능) : 불필요한 Pod 연결 금지

  3. Pod 구간 암호화
    2개 이상의 Pod 통신을 안전하게 하기 위해 TSL v1.2 이상 적용한다.
    Pod 간에 연결하고자 하는 구간은 평문 전송 금지

  4. 중요 데이터 보안
    도커/쿠버네티스에서는 Base64 기반 암호화를 적용하고 있다, 그러나 이는 취약한 암호화 알고리즘이다. 이를 해결하기 위해 서드파티 보안 관리 솔루션 (HashiCorp Vault, 등)이용.

  • 민간기업에만 사용(아직 미인증)

국내 기준 : 국정원 암호화 알고리즘 솔루션 존재. 이는 대칭키 기반이다. 과기부, KISA에서 암호키 알고리즘 가이드문서 참고
공공기관 : 국정원 홈페이지 암호키 관련 솔루션 가이드라인 참고

  1. etcd 보안 (엣-시디)
    etcd에 저장하는 모든 K8S 구성 데이터에 대한 보안 적용
    모든 클러스트 데이터에 대해 K8S 백업 저장
    공격자가 etcd 접근 시, API Server 우회 불가능하도록 설정
    클러스터(애플리케이션 컨테이너 실행 목적을 가진 일련의 노드)에 무제한 접속 제한 설정

  1. 컨테이너 데이터, 이미지 백업 및 복구
    취약 데이터, 손실 데이터, 랜섬웨어 데이터 보호 정책 적용
    신용카드 정보, 개인의료정보, 기타 개인정보, 교유식별정보 등데이터 백업 정책을 적용한다.
    주기적인 백업 및 복구 테스트를 진행한다.

  2. 컨테이너 보안정책 구성
    컨테이너 보안정책 정의해 특정 구성 적용한다.
    컨테이너 보안정책
    - Root 권한으로 실행하는 Pod를 허용하지 않는다.
    - 네트워크의 보안적책은 모든 Pod에 대해 정의한다.
    보안 구성 검증 자동화 설정 고려

  1. 컨테이너 재해 복구 계획
    클라우드컴퓨팅 서비스 호나경의 컨테이너 재해 복구 전략계획 수립
    컨테이너 복구 절차 및 테스트 시행
    컨테이너 이중화 구성

물리적 망분리(서로다른 AZ)에서 서버 이중화 구성이 보다 더 안전하다.

Cloud Native Container Security

Cloud Native 구성요소
1. Container
2. DevOps
3. CI/CD(Continous Integration and Continuus Development) : 지속적 통합 및 지속적 개발
4. MSA(Micro Service Architecture)

클라우드 네이티브 보안의 핵심요소 4C는 아래와 같다.
1. Cloud
2. Cluster (K8S는 클러스터 네 컨테이너 오케스트레이션 수행 플랫폼)
3. Container
4. Code

이전에서 기술한 Container 보안 내용과 중복이 되는 내용은 제외하고 쿠버네티스 관점에서의 4C 보안에 대해 기술한다.

Cloud 보안

클라우드 관점 보안

CSP는 신뢰 컴퓨팅 기반(trusted computing base)에서 워크로드를 안전하게 실행하기 위한 보안 권장사항을 제시한다.

클라우드 공급자 보안

CSP는 보안문서 등으로 쿠버네티스 클러스터 실행 시, 모범사례를 설명하고 있다.

API 서버에 대해 네트워크 접근(컨트롤 플레인)

노드 네트워크 접근

CSP API에 대한 K8S 접근

etcd 대한 접근

etcd 암호화

Cluster 보안 관점

클러스트 보안 관점은 클러스터 컴퓨넌트 보안, 클러스터에서 실행되는 애플리케이션의 보안 두 가지로 나뉘어진다.

클러스터의 컴포넌트

클러스터 내 컴포넌트(애플리케이션)

RBAC 인증

역할 기반 접근 제어를 통한 권한 부여는 rbac.authorization.k8s.io API 그룹을 사용하여 권한 부여 결정을 내리고, Kubernetes API를 통해 정책을 동적으로 구성할 수 있도록 한다

인증

AAA 인증 사용

  • 인증 / 전송 보안 부문 : API 통신 공격을 회피하기 위해 디폴트 네트워크 인터페이스 포트 변경
  • 인증 / 권한 부문 : MFA
  • 인증 / 인가 부문 : 특정 사용자로부터 온 요청이 인증된 이후에 인가되어야 한다.

애플리케이션 시크릿 관리

컨테이너 내 애플리케이션이 존재할 때, 해당 어플리케이션 이용 시 어플리케이션 주요 정보, 접근 통제 부문에 있어 인증된 사용자 만이 인증 가능해야 하고, 암호화를 통해 데이터를 사용해야 한다.

Pod 보안 정책 확인

K8S에서는 Pod 보안 표준을 적용하기 위해 기본 제공 Pod 보안 어드미션 컨트롤러를 제공한다.
pod 네임스페이스를 부여한다. pod 통신 시 네임스페이스 pool에 대해 접근 NACL 정책 반영 필요.

서비스 품질

특정 QoS 클래스 할당 목적으로 어떻게 Pod 구성해야 하는지 보여준다.
K8S는 QoS 클래스를 사용해 Pod 스케줄링과 축출을 결정한다.

취약점 분석 시 OWASP 취약점 분석 툴 다운로드 후 사용하면 된다.
시큐어 코딩 시, C, JAVA 는 존재하나.
그외 언어는 해외 사이트 찾아야 한다.

K8S Offical CVE

쿠버네티스 홈페이지에서 공식 CVE를 확인 가능하다.

Docker CVE

CVE details 페이지에서 Docker CVE 확인 가능하다

DevOps

DevOps 프로세스

DevOps 준 자동화 프로세스이다. 기존의 개발환경과 차별화 되는 점은, 파이프라인 기반의 자동화 환경을 구성해 DevOps팀에서 개발, 운영을 모두 수행.

참고 사이트

개발 단계를 어떻게 진행할 것인지에 대한 방법론(애자일, 폭포수, DevOps..)
1. 설계
2. 코딩
3. 빌드
4. 테스트
5. 배포
6. 배치
7. 운영
8. 모니터링

  • DevOps에서 자동화 외 코드 품질 및 안전성 문제를 해결하는 개념이 DevSecOps이다.

DevSecOps 프로세스별 보안 역할

DevSecOps 단계별 보안담당자의 역할 및 보안활동을 기술한다.

  • 보안 코딩
    laC(라크): 코드에 오류 분석, 컨테이너 OS 호환성, 컨테이너 운영사항 특이성 발견
    보안 코딩 단계만 포함된 보안 컨설팅은 드물다.
  • 개발 CSD 관점에서 해당 지식을 보유한 사람이 드물다. 즉, 보안에 관련해 잘 준비 후 코딩에 들어가기보다 바로 코딩 단계로 진입한다.
  • 지속적 빌드, 통합 및 테스트
    컴파일이 아닌 빌드 단계로 명시한 이유는? 코딩이 아닌 제반 관점을 고려하기 위해서이다.
    빌드 : 코드가 컨테이너 등에서 실행도리 수 있는 바이너리 코드화 시켜주는 것.
    모의해킹 진단
    민간기업, 공공기관 대상 : 과학기술정보통신부고시 주요정보통신기반시설 취약점 분석평가 가이드 > 웹 점검항목 28개
    금융회사, 전자금융업자 대상 : 금융위원회 전자금융기반시설 취약점 분석평가 기준(매년 갱신: 금융보안원) > 웹 점검항목
    성능 테스터 : 요구사항 충족 확인한다. 인프라, 플랫폼 및 애플리케이션에 대한 부하 및 스트레스 테스트를 위한 테스트 계획을 작성하고 실행하는 업무 담당한다.
  • 지속적 전달 및 배포
    환경 분리 : 개발과 운영 환경은 논리적으로 구분되어 있어야 한다. (예시1. 클라우드 인프라 구조 상에서, 서로다른 서브넷에 개발망, 운영망을 구성한다, 예시2. 동일 AZ 내 서로다른 컨테이너에 개발 전용 테스트 및 랩 환경, 실제 애플리케이션 구동 환경으로 논리적 망 분리를 실행) 이 망 분리는 CSP 안전성 평가 기준을 충족해야 한다.
    CI/CD 파이프라인 보안 : 지속적인 통합(Continuous Integration, CI), 지속적인 전달/배포(Continuous Delivery/Deployment, CD)
  • 런타임 보호 및 모니터링
    카오스 엔지니어링 : DDoS 대비 클라우드형 SEIM 구축.
    취약점 점검 및 제거: 모의해킹, CVE 취약점 점검 연 1회

단일 테넌트와 멀티 테넌트

SaaS 아키텍처의 최소필수요소 테넌트
가상화, 일부 클라우드 환경(공공기관, 금융기관) : 싱글 테넌트
클라우드 환경 : 멀티 테넌트

단일 테넌트

  • 1명의 CSV, CSC가 애플리케이션에 접속하는 형태
  • 하나의 SW와 지원 인프라가 단일 고객에게 제공되는 환경

멀티 테넌트

  • 두명 이상의 CSU, CSC가 애플리케이션에 접속하는 형태
  • SW 애플리케이션의 단일 인스턴스가 여러 고객에게 서비스를 제공하는 아키텍처

멀티 테넌트 종류

멀티 테넌트는 배치 방식에 따라 보안성의 특징을 가지고, 이를 3가지로 구분할 수 있다.
단일 애플리케이션 및 분리 DB 방식을 가장 많이 사용한다.
1번으로 갈수록 보안성이 높아지지만, 비용이 높고, 3번으로 갈수록 보안성이 낮아지며 비용이 낮다.
만약 금융기관, 공공기관에서 3번째 배치 방식을 채택하기 위해 추가적인 보안 처리가 필요.

  1. 분리 애플리케이션 및 분리 DB 사용
    seperate 애플리케이션
    seperate DB

  2. 단일 애플리케이션 및 분리 DB
    one 애플리케이션
    seperate DB

  3. 단일 애플리케이션 및 단일 DB
    one 애플리케이션
    one DB

프로비저닝

프로비저닝이란? 어떤 종류의 서비스든 사용자 요구에 맞게 시스템 자체를 제공하는 것. 제공하는 것은 인프라 자원, 서비스, 장비가 될 수 있다.

  • 프로비저닝 종류
  1. Server Resource Provisioning
  2. OS Provisioning
  3. SW Provisioning
  4. Account Provisioning
  5. Storage Provisioning

클라우드 기반 VPC 아키텍처

클라우드 기반 VPC 아키텍처에서의 3계층 가상 네트워크 보안정책은 인터넷 게이트웨이(IG), Subnet 수준 NACL, 보안그룹(SG)가 존재한다.
보안그룹(SG)이 가장 강력한 보안 기능을 가지고 있다. 즉, 가장 작은 단위의 보안 정책이다. (인, 아웃바운드 TCP/IP 설정으로 허용여부 결정)

VPC 간 네트워크 연결 방식 종류



VGW : VPC 간 연결(Peering), 같은 리전 내에서 VGW 가능.

DGW : VPC간 전용 연결(Direct)

TGW : VGW 내 온프레미스 데이터센터와 연동

통신구간 SSL을 사용중이고 DGW 연결 방식을 사용중이라면, TLS, IPsec 방식을 사용해 S2S VPN을 사용한다.

클라우드 DMZ*Private 구조

클라우드 CSP 제공하는 DMZ 사용한다.
CSP 외에는 서드파디에서 제공하는 DMZ 사용(드문 경우)

DMZ는 WEB, WAS 방식으로 나뉜다.

  • DMZ-WEB : AWS(Internet Gateway Route Table), Private 구성 기능을 위해서는 Private-DB를 사용한다.

클라우드 네이티브

클라우드 상주하도록 설계된 애플리케이션을 뜻한다.

클라우드 네이티브 요소
1. DevOps
2. CI/CD
3. 컨테이너 기반 인프라
4. Microservice

CNCF Architecture MAP

ctr : 컨테이너 에이전트 서비스
벤더사를 이용해 자체 클라우드 환경에 맞춰 클라우드 플랫폼을 이용한다.

Git vs GitHub

클라우드 환경에서 이미지 저장, 등은 Github 사용한다.
Git은 로컬 저장소로 사용한다.
GitHub 은 오픈소스 기반 SW이다.
상용 목적으로 사용 시, GitHub 지양. (테스트, 개인목적 예외)

교차 클라우드 아키텍처

온프레미스, 오프프레미스, Multi-cloud 등의 교차 클라우드 아키텍처가 존재한다.
각 환경에 맞는 고유한 관리 도구 집합 사용하기 위해 교차 클라우드를 구성한다.
CSP 통해 다중 클라우드 및 온프레미스 관리 플랫폼 구축 가능

profile
磨斧爲針

0개의 댓글