Ninano Tech Blog

ArgoCD는 RBAC을 활용하여 사용자의 계정 및 권한을 설정한다.

공식 가이드 : https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/

Admin 권한을 가지는 admin 계정이 이미 존재하는 경우, 다른 권한을 가진 계정 생성 방법에 대해 알아보겠다.

현재 계정 목록 조회

먼저 현재 계정 목록을 조회 하기 위하여 아래와 같이 admin 계정으로 로그인한다.

$ argocd login <hostname> --username admin --grpc-web-root-path --password <admin-password>

계정 목록을 조회한다.

$ argocd account list

새로운 계정 추가

admin이 아닌 새로운 계정을 추가한다.

argocd 설치시 함께 설치되는 configmap 중 argocd-cm 에서 추가할 수 있다.

현재의 argocd-cm configmap 설정을 아래와 같이 yaml 형태로 저장한다.

$ kubectl get configmap argocd-cm -n argocd -o yaml > argocd-cm.yml

저장한 argocd-cm configmap 에 신규 계정을 추가한다.

data:
  accounts.<new-username>: apiKey, login

신규 계정 추가 후 변경된 configmap을 클러스터에 반영한다.

$ kubectl apply -f argocd-cm.yml

추가된 user의 비밀번호를 변경한다. 이때, current-password로 앞에서 로그인 하였던 admin password를 입력한다.

$ argocd account update-password --account <new-username> --current-password <admin-password> --new-password <new-password> --grpc-web

추가된 계정을 확인한다.

$ argocd account list

계정의 권한 변경

신규 추가되는 계정은 기본적으로 read-only 권한을 가지게 된다.

argocd에서는 제공하는 정책이 있는데, admin과 read-only 정책이다.

좀더 세부화된 권한을 설정해보겠다.

configmap중 argocd-rbac에서 권한 설정이 가능하다. 아래와 같이 argocd-rbac.yml 파일을 저장한다.

$ kubectl get configmap argocd-rbac-cm -n argocd -o yaml > argocd-rbac.yml

적용하려는 권한(role)과 정책(poilicy)을 추가한다.

data:
  policy.csv: |
    p, role:app-admin, applications, *, */*, allow
    p, role:app-admin, clusters, get, *, allow
    p, role:app-admin, repositories, get, *, allow
    g, <new-user>, role:app-admin
  policy.default: role:''

• app-admin이라는 role에 application의 모든 권한을 모든 project에 대해 부여한다.
• app-admin이라는 role에  cluster의 get 권한을 모든 클러스터에 대해 부여한다.
• app-admin이라는 role에 repository의 get 권한을 모든 repository에 대해 부여한다.
• g, <new-user>, role:app-admin → <new-user>에 app-admin 권한을 적용한다.
• policy.default: role:' ' :  default 권한인 read-only 를 적용하지 않는다.

변경된 rbac을 적용한다.

$ kubectl apply -f argcd-rbac.yml

적용가능한 권한(builtin-policy)은 아래 링크에서 확인 가능하다.

https://github.com/argoproj/argo-cd/blob/master/assets/builtin-policy.csv

Providers

• Official : Terraform (AWS, GCP, Azure…)
• Verified : 3rd party. heroku …
• Community

terraform init

여러번 수행해도 아무 문제 없다.

단순히 Provider Plugin을 받는것. ~/.terraform/Plugin 에 설치

Hostname/Organizational Namespace/type 형태로 설치됨

Plugin은 최신 버전으로 다운 받는다.

Configuration Directory

테라폼은 해당 경로에서 확장자가 tf인 파일은 전부 다 읽어서 처리함

보통 main.tf , variable.tf, output.tf, provider.tf 로 지정

Variables

variable 로 시작하여 선언

var.변수명으로 사용

type이 LIst인 경우: var.변수명[0] 부터 시작. 인덱스는 0부터 시작

type이 Map인 경우 : var.변수명[“키명”]

type이 set인 경우 : list와 비슷하지만, 중복할 수 없다. 중복 요소가 있는 경우 에러 발생

type이 Tuple인 경우 : 리스트와 비슷하지만, 각각의 요소들이 각각의 type을 가질 수 있다.

Variable에 default 값을 입력하지 않을 경우, terraform 명령 수행시 직접 입력해야 한다.

Variable 선언 방식

Environment Variable : export TF_VAR_변수명

*.tfvars 파일에 선언

*.auto.tfvars 파일에 선언

명령어로 선언

variable.auto.tfvars 에 입력하면 자동으로 var 입력이 된다.

variable 입력 순서. 뒤로 갈수록 앞의 순번의 것을 덮어쓰므로 더 우선순위가 된다.

1번. Environment Vairables : $export TF_VAR_filename=”/root/cats.txt”

2번. terraform.tfvars : terraform.tfvars에 선언

3번 variable.auto.tfvars : 파일에 선언

4번 명령어 플래그 : terraform apply -var “filename=/root/cats.txt”

Resource Dependencies

Implicit Dependency : 암묵적으로 다른 리소스의 속성을 가져다 쓰는경우. 먼저 지워야한다.($resource_type.resource_name.attribute)

Explicit Dependency : depends on으로 명시적으로 기술한 경우 (왜 이걸 쓰는지 확인 필요)

Output Variables

output 블럭 사용

output “변수명” {
value = variable_value
….
}

$ terraform output 으로 모든 output 변수를 확인할 수 있다.
$ terraform output 변수명 으로 해당 변수명에 대한 값을 확인할 수 있다.

앤서블이나 쉘 스크립트에서 사용가능하다.

Terraform state

terraform init : plugin 받는다

terraform plan :

terraform apply :

terraform.tfstate : 테라폼 스테이트 파일. apply 명령어로 생성됨. json 데이터 구조. 테라폼 명령어로 생성된 모든 인프라가 적혀 있음. single source of truth 로 사용됨
plan 시 tfstate 파일과 비교해서 작성하게 됨

tfstate 파일 사용
– 종속관계 파악 : 리소스들간의 종속성을 파악하여, 생성/삭제 시 디펜던시가 있는 리소스 먼저 삭제한다.
– 성능 : tfstate 파일을 직접 사용할 뿐만 아니라 캐싱 처리도 해둠. 대규모 인프라를 사용하는 곳에서는 매번 tfstate 파일을 refresh 하면 시간이 많이 걸리기 때문에 terraform plan –refresh=false와 같은 명령어로 캐시에서도 사용가능함
– Collaboration : 팀으로 일하는 경우 terraform.tfstate 파일을 팀원간에 공유하여 remote state로 관리한다.

tfstate 고려할점
– state 파일은 민감한 정보를 포함한 인프라의 모든 정보를 다 담고 있다. DB라면 비밀번호도 가지고 있다.
– state 파일은 안전한 스토리지에 저장해두어야 한다.
– tf 파일은 깃헙 정도면 되지만, state 파일은 S3나 gcp bucket 같은 안전한곳에 보관한다.
– tfstate 파일을 직접 건드리지 않는다.

terraform 명령어

– terraform validate : tf 파일이 유효한지 확인한다.
– terraform fmt : tf파일을 보기 좋은 형태(cannonical format)로 변경해준다.
– terraform show : 생성된 인프라의 모든 정보를 다 보여준다.(-json 플래그로 json 형태로 표시가능)
– terraform providers : provider 정보를 다 보여준다.
– terraform output : 결과로 생성되는 변수를 다 보여준다.
– terraform refresh : 테라폼으로 만든 인프라를 수동으로 수정한 경우, tfstate 파일을 현재 상태에 맞도록 수정한다.
– terraform graph : apt install graphviz -y 설치하여 terraform graph | dot -Tsvg > graph.svg 로 파일 생성 후 파일 열면, 리소스 간의 형태를 그래프형태로 볼수 있다.

Mutalbe vs Immutable Infrastructure

테라폼은 왜 인프라를 다 부셨다가 다시 만들까? 서버의 버전을 올린다고 생각해보면, 서버 여러대를 운영할 경우 기존 서버를 업그레이드 하는 건 업그레이드 과정에서 여러가지 이슈가 발생할 수 있다.(configuration drift) 서버들이 운영 중에 미묘하게 차이가 날 수 있다.

따라서 버전이 올라간 서버를 새로 만들고, 오래된 버전의 서버를 폐기한다. -> Immutable Infrastructure 버전을 올린 서버에 문제가 생긴 경우, 다시 이전 버전의 서버를 살린다. 인프라 스트럭처에 버저닝을 하는건 롤백도 쉽고, 운영도 쉽다.