개발자로 취업하려고 node 공부중입니다.

PCI

컴퓨터 메인보드에 마우스, 키보드등 주변 장치를 장착시키는 데 쓰이는 컴퓨터 버스의 일종

ip link

리눅스의 네트워크 인터페이스 확인 및 설정하는 명령어이다.

네트워크 카드의 설정을 변경하거나 확인하려면 ethtool을 이용하면 된다.

ethtool <NIC 이름>

Ubuntu에서 파생된 GUI 기반 리눅스이다. - 한국정부가 윈도우를 벗아나기 위한 대안의 리눅스

패키지 및 소프트웨어 설치

1. 우분투와 같은 방법으로 CLI를 이용

sudo apt-get install <프로그램>
sudo add-apt-repository <추가할 레파지토리>

2. Manager를 이용해서 설치 가능

Software, Package, Update Manager가 있음

민트 버전 확인

cat . /etc/issue* 
hostnamectl
cat /etc/os-release

서비스 목록 확인

sudo systemctl list-unit-files --type=service <전체 서비스>
sudo systemctl status <서비스 이름>
sudo service <서비스 이름> status

systemctl vs service

리눅스의 데몬 프로세스는 d가 끝에 붙는다. ex) systemd, syslogd 등

Service: OS가 부팅 되었을 때, 생성되어 종료될 때까지 실행되는 프로세스 or 설정파일을 말한다.

Systemctl : 서비스 유닛을 관리 및 제어하는 명령어이다. (OS에서 시작 데몬을 init에서 systemd로 옮기면서 관리하는 명령어 모음)

CloudFront?

Amazon CloudFront는 .html, .css, .js, 이미지 파일, 동영상 파일등 정적 웹 콘텐츠 그리고 동적 웹 컨텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스이다.

안전하고 안정적인 AWS 글로벌 네트워크에서 실행되어 보안과 가용성, 고성능이 보장되며 글로벌 네트워크여서 광범위한 글로벌 서비스가 지원이된다.

Edge Location (Pop)

AWS는 글로벌 엣지 네트워크를 가지고 있다. "짧은 지연 시간과 처리량을 지원하는 안정적인 네트워크 연결"

전 세계에 이동 통신사와 협력하여 주요 엑세스 네트워크에 연결되어 엣지 로케이션을 만들었다. 

엣지 로케이션은 AWS 리전과 AWS 네트워크 백본으로 연결되어 있다.

-> 고객과 가까운 위치에 콘텐츠 사본을 캐시하는 캐시 서버이다.

Regional Edge Cache

CloudFront의 엣지 로케이션과 Origin 서버 사이에 위치한 캐시 서버로 Pop 보다 조금 더 오래 캐시를 보존하는 서버이다. Pop과 Origin 사이의 직접적인 통신을 대신해 Origin 서버의 부하를 추가로 줄일 수 있다.

CDN

Contents Delivery Network 서비스 콘텐츠를 보다 빠르게 전송하는 기술로, 속도 개선과 회선 비용 절감에 용이하다.

최초 요청시 CDN 장비에 요청을 하면 CDN 장비가 Origin 서버에 요청 후 캐싱하고 그 후 CDN 장비와 클라이언트가 서로 통신한다.

-> 사용자에게는 더 빠른 응답과 원본 서버에는 부하도를 줄이는 장점을 가지고 있다.

주 목적

대기 시간을 줄이거나 네트워크 설계로 인해 발생하는 통신 지연을 줄이는 것입니다. 

EKS Cluster의 Service Account에 IAM Role을 부여 = IRSA(IAM Roles for Service Accounts)

완벽하지는 않지만 공식 홈페이지와 다른 블로그를 참조해서 정리를 해보았다.

쿠버네티스에서 요구 사항에 맞는 IAM 역할을 생성할 수 있다. -> Pod 수준에서 세분화된 역할을 생성하여 최소 권한의 보안 원칙을 가능하게 한다. -> 클러스터에 대한 IAM OIDC 공급자를 연결 = 클러스터에는 OIDC 발급자 URL이 이미 존재

각 EKS Cluster 마다 가지고 있는 전용 OIDC Identity Provider를 나타낸다. AWS IAM에게 신뢰하는 OIDC Identity Provider로 등록(Federate)되어 있다. -> 클러스터를 생성하면 OIDC 인증기관 주소가 함께 생성되어 제공이 된다.

해당 주소를 이용해서 Provider를 생성할 수 있다.

IAM 역할을 생성하고 역할을 쿠버네티스 서비스 계정과 연결한다.

eksctl create iamserviceaccount --name {serviceaccount 이름} --namespace {서비스 계정을 생성할 네임스페이스} --cluster {클러스터 이름} --role-name {IAM Role 이름} \
--attach-policy-arn arn:aws:iam::{계정 ID}:policy/{적용하려는 정책 이름} --approve

정상적으로 서비스 어카운트가 생성이 되면 결과물에 oidc.eks라는 결과가 Condition에 나타난다.

또한 쿠버네티스 서비스 계정에 역할이 annotaions로 달린다.

Private/ Public Key : AWS EKS OIDC provider와 쿠버네티스 API 서버는 동일한 Key를 공유하게 된다.

Pod Identity Webhook : API 서버로 요청을 보내면 API 서버가  Mutating Webhook에 요청 Pod가 IAM Role을 가진 Service Accout를  이용하는 경우 Pod 내부에서 Service Account에 부여된 IAM Role을 이용할 수 있도록 Spec을 변경한다.

Mutating Webhook?

쿠버네티스는 접근 제어를 3단계로 진행한다. 1 Authentication(인증) 2. Authorization(인가) 3. Admission Control(?)

Admission Control : 인증과 인가를 통과한 사용자에 한해서 Admin이 추가로 특정 행동을 제한 혹은 변경하는 작업 -> 세부 작업에 대한 지침 사항 이때 2단계를 걸쳐서 제한, 변경이 되는데 Mutata, Validate이다.

Mutata

사용자가 요청한 매니페스트를 검사해 적절한 값으로 수정하는 변형 작업

Validate

매니페스트가 유효한지 검사 함으로써 요청을 거절 할것인지 결정한다.

쿠버네티스 특징으로 API로 통신이 되는데 Webhook으로 Admission Control을 동작 시킬 수 있다.

MutatingWebhook : 사용자가 요청한 Req에 대해서 관리자가 임의로 값을 변경하는 작업 ValidatingWebhook : 사용자가 요청한 Req에 대해 관리자가 허용을 막는 작업-> 인증, 인가를 통과한 후 Mutat 한 뒤 변경된 내용을 Validate (검증) 후 etcd에 저장 후 작업이 이어진다.

Projected SA Token : IAM Role이 부여된 Service Account의 Token을 나타낸다.(K8s의 Service Account Token과 별개의 Token) = JWT 형태

Projected SA Token가 Pod에 있어도 AssumeRoleWithWebIdentity(임시 보안 자격 증명)을 사용하기 위해서는 OIDC의 정보를 담은 JWT Token이 필요하다. 원래라면 OIDC의 ID Token(인가를 위한)이 필요한데 API 서버가 OIDC의 Private/ Public key를 가지고 있어서 직접 JWT Token을 생성해서 Pod에 주입한다.

IAM Role 부여 과정

0. EKS 클러스터의 OIDC Provider를 생성해 Private/ Public Key를 Provider와 K8s API Server가 공유한다.

1. eksctl을 이용해서 iamserivice account를 생성한다. "eksctl create iamserviceaccount"

2. Pod를 생성 할 때 service account를 넣어서 생성한다. (aws lb controller 를 배포 할떄 포함되어 있다)

3. K8s API 서버로 Pod 생성요청을 보내면 API 서버가 serviceaccount를 확인해 Pod Identity Webhook에 의해 강제로 Pod에 '부여 받는 AWS IAM Role, JWT Token의 위치, 클러스터 리전 정보'가 주입 된다. = Spec Mutate

JWT Token의 위치는 aws-iam-token 이름의 Projected SA Token Volume을 생성하고 Mount하도록 만들고 Projected SA Token으로 저장된다. (만료시간, Audience 설정도 포함)

3-1. Token을 바로 Pod에 저장될 때 API 서버에게 SA Token을 요청하고 받아서 Pod에 Projected SA Token을 저장한다.

4. Mutate된 Pod 생성 Req를 Kubelet에 API 서버가 보내서 kubelet이  Pod를 생성한다.

5. Pod가 AWS STS/IAM에게 Projected SA Token의 credential(자격증명)을 요청 하면 AWS STS/IAM은 AWS EKS OIDC Provider에게 검증을 하는데 Projected SA Token은 같은 키를 가진 API 서버가 만든 Token 이어서 검증을 성고해 자격증명을 허락한다.

6. 허락된 Pod는 AWS 리소스에 접근 및 사용 권한을 가지고 요청이 가능해진다.

EKS와 OIDC 관계?

EKS가 AWS의 LB를 이용하기 위해서는 AWS Loadbalancer Controller를 설치해야 한다.

AWS Load Balancer Controller는 Kubernetes 클러스터의 AWS Elastic Load Balancer를 관리합니다. 이 컨트롤러는 다음 리소스를 프로비저닝합니다.

AWS Loadbalancer Controller는 클러스터 내에 Pod로 배포가되어 동작하는데 Pod가 AWS 리소스인 LB를 생성하거나 지우기 위해서는 IAM Role, Policy가 필요하다. 

이 때 사용되는 것이 IRAS (IAM Role for Service Account) 개념이다.

쉽게 설명하면 Pod에게 IAM Role을 부여해주는 Service Account를 만들어 접근 권한, 사용 권한을 얻는것이다.

IRAS?

우선 RBAC(Role Based Access Control)에 대해 알아야 한다. '역할기반 접근제어'라는 뜻으로 시스템 보안에서 권한이 있는 사용자들에게 시스템 접근을 통제하는 방법이다. -> RBAC는 보안에대한 부분이다.

K8S에서 접근을 제어하는 방법은 Role, RoleBinding, ServiceAccount 객체들을 이용할 수 있다.

Role이 바인딩된 ServiceAccount를 Pod에 할당함으로 Pod는 지정된 Role을 사용 할 수있다.

AWS는 IAM을 이용해 RBAC를 구현했다.

EKS에서는 Service Account에 annotation(임의의 비식별 메타데이터)를 통해서 IAM Role을 부여하고 이를 통해 Service Account를 사용하는 Service는 해당 권한을 갖는것

-> RBAC를 AWS IAM Role과 K8S ServiceAccount를 이용해서 구현한것을 IRAS라고 한다.

EKS는 사용자가 IAM 사용자를 인증받아 대상 클러스터에 kubectl 명령어로 접근 할 수 있으며 Cluster를 생성한 IAM 사용자 또는 역할의 ARN만 aws-auth ConfigMap에 추가한다. -> ConfigMap을 직접 수정 해야한다.

만약 IAM에서 EKS 관련 권한을 때려박은 사용자로 kubectl을 통해 접근하려고 하면 error: You must be logged in to the server (Unauthorized) 라는 에러가 발생한다. aws eks update-kubeconfig를 해도 마찬가지 이다.

밑의 블로그에서 EKS의 RBAC를 만드는 것과 IAM을 수동으로 묶어서 사용하는 내용이 있다.

OIDC?

어려운 이야기를 빼고 하면 인가와 인증을 같이해주는 보안 프로토콜이다.

OIDC는 AccessToken, ID Token이 발행되어 AccessToken은 접근 권한만 확인하고, ID Token이 신원정보를 가지고 있어서 인가와 인증을 한번에 할 수 있다.

해당 블로그에 그림으로 잘나와 있다.

1. Pod가 Role ARN, Token을 이용해 AWS 리소스에 접근 요청을 한다.

2. Token과 Role ARN정보를 가진 STS을 IAM에게 확인 요청을 보낸다.

3. IAM은 OIDC에게 Token을 검증한다.

4. 검증이 통과되면 Role에 Policy를 담아 STS에게 준다.

5. Pod는 인증된 STS를 받는다.

6. AWS 리소스에 접근해서 사용한다.

STS, Assume Role

신뢰관계가 생성된 계정의 IAM 사용자, AWS 리소스는 STS, Assume Role을 사용 할 수 있다. 2가지를 통해서 AWS 리소스에 엑세스 할 수 있는 임시 보안 자격 증명을 제공한다.

STS?

Security Token Service로 AWS에서 보안 토큰을 생성하는 서비스이다.

IAM Role, 외부 자격증명을 사용해 엑세스 권한을 부여 할 수 있다.

Assume Role

IAM에서 지원하는 기능으로 '역할 전환' : 잠시 상대의 권한을 사용하는 것이다.

Role이라는 '신뢰할 수 있는 사용자, 그룹, AWS 서비스'에 여러 Policy를 연결해 다른 AWS 리소스를 엑세스하는 권한을 가지게 하는 AWS의 특징을 구현해주는 2가지 서비스이다.

지 담당자(Principal)를 지정해야 하는 신뢰 정책(Trust Policy)이 추가 필

OpenID

오픈된 IDentity로 서로 연계된 서비스 간에 사용자의 인증 등을 오픈해 주는 기술이다. OpenID = OpenID Connect

IDP 

IDentity Provider Google, Apple과 같은 간편 로그인 서비스를 제공하는 회사, 특정 서비스(애플리케이션)에 로그인하기 위해서 별도 회원가입을 거치지 않고 바로 로그인할 수 있도록 사용자의 신원증명 또는 인증을 해주는 것이 IDP의 역할

IDP - SP(Service Provider) 사이 사용자 인증 증명 정보에 대한 통신이 OAuth로 OpenID로 대표되는 기술이다.

OpenID, OAuth, SAML 모두 SSO(Single Sign-On)에 포함되는 기술이다.

SAML

OAuth

인증, 인가

인증 : 사용자가 누구인지 확인하는 절차 = 회원가입을 통해 로그인 하는 것

인가 : 사용자에게 권한을 허락하는 절차 = 로그인을 통해 서비스를 사용할 자격을 얻는 것

AWS OIDC

IAM OIDC는 표준을 지원하는 IdP 서비스를 설명한다.

결론

OpenID는 OAuth 2.0 프레임워크 위에 구축된 인증 프로토콜이다.

OIDC는 클라이언트가 IdP에 의해 수행된 인증을 기반으로 최종 사용자의 신우너을 확인, 인증 및 권한 부여를 제공한다.

저번주 금요일에 EKS + CodeCommit + CodeBuild를 통한 CICD 파이프라인 구축에 성공을 했다.

오늘 다시 구축하면서 내부 파일을 업데이트 했는데 deployment가 pod unchanged라면서 kubectl이 무시되었다.

원인

deployment.yaml 입장에서는 Pull하는 이미지가 latest로 되어있는데 ECR의 이미지, 자신이 적용한 이미지 둘다 latest여서 적용을 하지 않고 변화 없음으로 넘어간 것이다.

해결

1. ECR Image에 latest가 아닌 버전을 붙이면서 관리한다. 

2. rollout restart를 통해서 Deployment를 재시작 한다. -> 추천(간단함)

준비기간?

약 한달간 준비 했습니다.

준비 방법

경기도일자리재단의 클라우드 아키텍트 수업과정의 AWS 공인 교육을 듣고 교육에서 나온 서비스와 실습을 2번정도 반복하면서 공부 했습니다.

2주전 부터는 덤프 문제를 푸는데 답을 외우는 방식이 아닌 문제에 나오는 서비스를 실제로 사용한다면 어떻게 사용을 할지 고민하면서 서비스들의 특징과 정답이 답인 이유를 찾으면서 공부했습니다.

시험 후기

2회, 3회 반복은 못해서 걱정은 됬지만 다행히 덤프에서 나온문제가 비슷하게 나왔습니다.
하지만 답이 똑같지는 않은 문제들이 많았습니다.

답의 위치가 다르든 답이 다르든 덤프 변형이라 생각하는게 좋을 듯 합니다. -> 덤프 그대로 외우지 말기

아예 처음보는 문제들도 있었지만 문제를 해석하며 풀어가니 다행히 합격한것 같습니다.

그리고 책상도 깔끔하게 치워버렸습니다. 제 책상에는 책장이 붙어있었는데 다른 인터넷 후기를 보니 책장을 가리라는 말이 있어서 도화지로 막아 버렸습니다.

결과는 약 5시간 정도 뒤에 나오는것 같으니 메일함 확인을 그때쯤 하면 될것 같습니다.

어제 실패한 것을 이어서 하면서 성공을 했다.

codebuild를 통한 eks 배포를 검색하면 좋은 블로그글이 많이 있지만 내 문제를 해결하는데 3가지 글이 많은 도움이 됬다.

error: You must be logged in to the server (Unauthorized) 오류 발생시 해결 방안 (tistory.com)

첫번째 블로그에서는 IAM 역할로 인한 문제와 aws-auth의 문제를 볼 수 있었다.

CodeBuild가 EKS에게 권한을 받기 위해서 EKS 정책들을 얻어야 한다. 지금은 연습이어서 Admin, FullAccess등을 설정하려고 했지만 EKS는 모든 정책이 없었다. EKS의 모든 정책을 주면 10개뿐인 정책이 다 차게되어 알아보고 넣어야 했다.

aws-auth에 mapRoles에 직접적으로 CodeBuild에 적용된 role의 arn을 rolearn에 추가 해주면 된다고 했다. 

BUT 여전히 실패했다.

https://repost.aws/knowledge-center/codebuild-eks-unauthorized-errors

2번째는 AWS 공식 리포트글을 참조 했다.

aws-auth에 직접적으로 ARN을 추가해주면 eks가 codebuild를 통과 시켜 줄 것이라고 생각을 했지만 에러는 여전했다.

error: You must be logged in to the server (Unauthorized)

aws에서 해당 error에 대해서 설명해주는데 

AWS Identity and Access Management (IAM) Authenticator doesn't permit a path in the role Amazon Resource Name (ARN) used in the configuration map. If the role ARN (rolearn) in your aws-auth ConfigMap includes a path, Amazon EKS returns the following error: error: You must be logged in to the server (Unauthorized)

IAM 구성 맵에 사용되는 ARN 역할의 경로를 허용하지 않습니다. aws-auth ConfigMap의 ARN(rolearn)에 경로가 포함되어 있으면 EKS는 오류를 반환한다. error: You must be logged in to the server (Unauthorized)

즉 CodeBuild 서비스의 역할 (자동 생성된)의 경로 문제 였다.

AWS에서 컨테이너 기반 CICD를 구성한다.

CodeCommit -> CodeBuild -> ECR

git을 CodeCommit에 연동해 git push로 CodeCommit이 변화가 발생하면 CodeBuild가 Buildspec.yml에 정의된 내용에 따라 Build를 실행한다.

pre_build : 선택적 시퀀스, 빌드전 CodeBuild가 실행 ex) ECR 로그인, npm 종속성 설치, kubectl 설치, cluster 연결

pre_build/commands : pre_build 지정한 경우 필수이다. 실제 실행내용

build : CodeBuild가 실행하는 명령, Mocha, RSpec등을 실행한다.

build/commands : build 지정시 나열된 순서로 처음부터 끝까지 한 번에 하나씩 실행한다.

post_build : build 후 실행하는 명령을 나타낸다. ex) Docker 이미지를 ECR로 푸시, SNS 빌드 알림

CodeBuild -> EKS

pos_build에서 kubectl apply -f deployment.yaml을 실행할 수 있다.

근데 이번에 deployment.yaml이 실패가 됬다. 

Error

You must be logged in to the server (the server has asked for the client to provide credentials)

한국어: 서버에 로그인해야 합니다. 서버가 클라이언트에게 자격 증명을 제공하도록 요청했습니다.

뭐가 문제인지 잘 모르겠다. 아마 access_key가 없어서 인가?