Ray`s Tech Lab

윈도우가 깔린 컴퓨터를 켜면, 처음에 어떤 유저로 들어갈 건지 고를 수 있다.

리눅스도 마찬가지다.

각각의 유저별로, 하나의 컴퓨터에 대해 할 수 있는 동작들이 다르다. 누구는 A를 할 수 있지만 누구는 할 수 없고 등등..

AWS도 이와 비슷하게 "유저들"이라는 개념이 있다.

조직원들이 쓰고 있는 전체 자원들에 대해, 누구는 A를 할 수 있지만 누구는 못 하게끔 설정이 가능하다.

AWS에서, "계정"과 "사용자"는 다른 개념이다.

계정은 root, 즉 리눅스에서의 super user같은 개념이다. 과금의 주체가 되는 주인이라고 보면 된다.

사용자는 이용자, 즉 root가 허가한 권한만 갖는 애들이라고 보면 된다. 위에서 방금 말했던 "유저들"이란 개념을 상기하자.

AWS계정을 처음 만들면 root 사용자로 시작하는 것이며, 모든 AWS서비스 및 리소스에 대한 전체 액세스 권한을 갖는다(모든 걸 다 할 수 있다는 의미).

그 후 root가 유저들을 만들면서 이 유저들한테 특정 권한들(어떤 리소스에 대해 어떤 동작을 허가한다와 같은)을 줄 수 있는 거다. 이것이 사용자라는 개념이라고 이해하면 된다. 관리자 유저한테는 ~~권한들을 주고, 개발자 유저한테는 ~~권한들을 주고, 감사자 유저한테는 ~~권한들을 주고 그런 식으로 세팅할 수 있는 것.

암튼.. 이런 것들에 대해 적용되는 개념이 IAM = Identity and Access Management이다.

IAM이라는 서비스와 구성요소

IAM은 한 줄로 말하자면 AWS에서 사용자를 만들고 권한을 주는 것을 통해 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있게끔 하는 서비스이다. 각 유저들에 대한 권한 제어는 policy(=정책)라는 json포맷의 텍스트(쉽게 말하면 "어떤 걸 할 수 있다"들의 목록같은 거다)를 통해 이뤄지며, IAM은 다음과 같은 4개로 구성된다.

• 사용자 : 위에서 말한 개념
• 그룹 : 각 사용자들을 그룹핑 가능하며, 그룹에 정책을 지정하면 그룹원들이 동일한 권한들을 갖게 할 수 있다
• 역할
• 정책

먼저 정책에 대해 얘기해보자.

다시 한 번 말하자면 "어떤 걸 할 수 있다"라는 것들..즉 "권한들의 목록"이 정책이다 라고 보면 되며, 사용자들은 이렇게 연결된 정책에서 지정된 권한들만 쓸 수 있다.. 그렇기 때문에 사용자를 만들고 그룹을 배정해주든 정책을 연결해주든 아무것도 안 해준다면 사실상 그 놈은 아무고토 할 수가 없다. 왜냐하먄 어떠한 권한도 없는 셈이니까. 리소스 기반 정책과 자격증명 기반 정책으로 분류할 수 있다

• 리소스 기반 정책 : "리소스"에 연결되는 정책. 예를 들면 S3 bucket에는 ~~만 액세스할 수 있다! 처럼
• 자격 증명 기반 정책 : "사용자나 그룹 또는 역할"에게 권한을 부여하는 식으로 사용하는 정책. 예를 들면 넌 EC2에 대해서는 읽기만 가능해! 등등

여기서 자격 증명 기반 정책은 다음과 같이 두 종류로 분류할 수 있다

• Inline Policy : 1 : 1로 사용되는 정책. 적용된 사용자가 없어지면 이 정책도 사라진다
• Managed Policy : 1 : N으로 사용되는 정책. 즉 정책을 object화해서 다른 애들한테도 이 정책을 멕일 수 있다. 적용된 사용자가 사라져도 이 정책은 남아있다.

여기서 Managed Policy는 다음과 같이 두 종류로 분류할 수 있다. 이번이 마지막임ㅋㅋㅋㅋ

• AWS managed Policy : AWS에서 미리 만들어둔 애들. 변경할 수 없다
• Customer managed Policy : 사용자가 생성한 정책! 

참고로 Customer managed Policy를 만들 땐 Policy generator라는 걸 쓰는게 좋다. 하나하나 타이핑해서 json파일을 만드는 것보단 프로그램을 통해 편하게 만들 수 있기 때문. 

(또한 이렇게 정책들을 다 멕인 후에, simulator를 통해서 이런저런 정책들이 적용된 상황에서의 테스트가 가능하다)

그 다음으론, 역할에 대해 얘기해보자.

얘는 쉽게 말해서, 임시로 권한들을 부여하는 기능(즉 당일 회수되는 임시 출입증을 발급하는..)이라고 보면 된다. 내가 원래 다른 권한들을 가지고 있어도, 특정 역할을 잠깐 맡는다면 그 역할에 부여된 정책들을 임시로 사용할 수 있는 거다.

주의할 점은 병합의 개념이 아니기 때문에, 기존에 정책들을 가지고 있던 사용자가 역할을 받으면 원래 가지고 있던 정책들은 가려진다. 즉 역할을 통해 임시로 받는 권한들만 사용 가능해진다.

참고로, AWS lambda와 같은 AWS 서비스들도 역할이란 걸 받을 수 있으니 알아두면 좋다:)

IAM에서 정책을 평가하는 방법

그럼 IAM에서 정책은 어떤 순서대로 적용될까? 한마디로 사용자에게 부여된 권한들은 어떤 순서로 평가돼서 특정 리소스들에 대해 얘는 거부되는 거고, 얘는 승인하는건지 평가되는지 알아보자.

참고로, AWS는 어떤 권한에 대해 명시적으로 언급하지 않았다면 그 권한에 대해 암묵적으로 Deny, 즉 거부가 된다. 명시적으로 Allow, 즉 승인을 해줘야만 그 권한을 이용가능하다고 생각하면 된다.

암튼 평가 순서는

1. 우선, 그 권한에서 이야기하는 작업이 명시적으로 거부되는지를 본다. 만약 명시적으로 거부했다면 더 볼 필요도 없이 해당 권한이 없는 걸로 결론짓고 제낀다. 명시적으로 거부되지 않았다면, 다음 스텝으로 넘어간다
2. 그럼 그 작업이 명시적으로 승인되는지를 본다. 만약 명시적으로 승인됐다면 그 권한이 있는 걸로 결론지어진다. 만약 그렇지 않다? 이는 그 권한에 대해 아무런 명시도 안 한 것이니 암묵적으로 거부했다고 판단한다. 즉 해당 권한이 없는 것으로 결론짓는다

뭐 이런 식으로 해당 권한이 있고 없고가 결정된다고 보면 된다. 이렇게 평가된 정책들에 대해, 사용자에게 부여된 자격 증명 기반 정책들을 통과하고, 리소스들에 부여된 리소스 기반 정책(VPC 엔드포인트 정책, S3 버킷 정책 등등)을 통과해야 비로소 해당 리소스에 접근할 수 있게 되는 것이다.

IAM 권한 경계

자격 증명 기반 정책들이 IAM 사용자들에게 부여할 수 있는 최대 권한을 설정하는 기능이다. 즉 나한테 부여된 정책들 중 내가 쓸 수 있는 정책들을 제한해주는 기능이라고 보면 된다. 따라서 권한 경계와 나에게 부여된 자격 증명 기반 정책의 교집합이 내가 쓸 수 있는 정책이 될 것이다.

AWS orginizations

다중 계정을 관리하는 것을 말한다. 사용자들을 그룹핑해서 그룹을 만들어주던 것을 계정에도 그대로 적용해서, 계정들도 조직을 만들어 그룹핑함으로써 특정 조직은 어떤 걸 할 수 있게 하고, 특정 조직은 어떤 걸 못 하게 하고 이런 걸 설정할 수가 있다. 

이렇게 조직에 허가되는 정책을 SCP(Service Control Polity)라고 한다. 즉.. 사용자는 자신이 속한 계정이 속한 organization에서 허가된 권한들만 쓸 수 있는 거..

정리하면, 내가 만약 AWS에서 뭔가 작업하고 싶다면

1. 일단 내가 속한 계정의 조직이 이 작업을 허용했는지 봐야 하고
2. 적용된 IAM 권한 경계를 따져서 내가 할 수 있는 건지 봐야하고
3. 내게 부여된 자격 증명 기반 정책이 이 작업을 허용하고 있는지

를 따지게 되는 거다.. 이렇게 보니 꽤나 복잡한 듯

CI란?

Continuous Intergration의 줄임말로, 지속적인 통합을 의미한다. CD(Continuous Delivery&Deployment)와 짝꿍 관계기도 하다. 

그럼 지속적 통합은 뭘까? 우선 통합의 의미를 살펴보자. 나 또는 다른 사람이 어떠한 코드 변경(새로운 기능 추가, 수정, 삭제 등)을 했을 때 그 코드가  빌드 및 테스트되어 우리의 공유 리포지토리(깃헙 등)에 병합되는 걸 통합이라 부른다. 지속적 통합이란, 이 과정이 정기적으로 계속해서 일어난다는 것을 의미하는 것이다.

이는 다수의 개발자가 다 함께 코드 작업을 할 경우, 서로 충돌이 일어날 수 있는 문제를 해결하기 위해 도입된 개념이라고 한다. 통합 과정을 주기적하게 되니, 자연스럽게 충돌 과정이 최소화된다는 거다. CI는 다시 말해 빌드 및 테스트를 자동으로 실시하여 공유 리포지토리에 통합하는 과정이라고 이해할 수 있으며, 이를 통해 코드 변경 내용을 우리 손을 거치지 않고 자동으로 빌드하고 테스트할 수 있다.

GitHub Action이란?

GitHub에서 제공하는 서비스로, CI & CD 플랫폼이다. 리포지토리에 .github폴더를 만들고, 그 안에 workflows폴더를 만든 뒤 그 안에 yaml파일을 만드는 것으로 구축할 수 있다. 그러면 어떤 동작이 발생했을때, yaml파일에 내가 작성했던 workflow가 실행되게 할 수 있다.

플러터 프로젝트 CI 구축

GitHub marketplace에 flutter란 이름으로 검색하면, Flutter Action라는 이름의 Action이 있다

https://github.com/marketplace/actions/flutter-action

친절하게 사용법이 나와있어서 따라하면 된다.

난 우분투, 윈도우, 맥 모두에서 테스트 & 빌드를 해볼 수 있게끔 만들었다.

name: Flutter CI (test & build)

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]
    
jobs:
  Tests-and-build-ubuntu-and-window:
    name: Tests and Build on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-java@v2
        with:
          distribution: 'zulu'
          java-version: '11'
      - uses: subosito/flutter-action@v2
        with:
          flutter-version: '3.10.0'
          channel: 'stable'
      - run: flutter pub get
      - run: flutter test
      - run: flutter build apk
      - run: flutter build appbundle

  Tests-and-build-macos:
    name: Tests and Build on MacOS
    runs-on: macos-latest
    steps:
    - uses: actions/checkout@v3
    - uses: subosito/flutter-action@v2
      with:
        flutter-version: '3.10.0'
        channel: 'stable'
        architecture: x64
    - run: flutter pub get
    - run: flutter test
    - run: flutter build ios --release --no-codesign

uses : 다른 사람들이 이미 만든 action을 이용하는 것

run : 직접 커맨드를 실행하는 것

이라고 이해하면 된다.

[ runs-on ] 작업들이 실행될 인스턴스 환경(OS)

[ uses: actions/checkout@v3 ] 작업한 깃헙 레포지토리의 소스코드 가져오기(일단 코드를 가져와야 테스트하든 빌드하든 하니까)

[ uses: actions/flutter-action@v2 ] 플러터 SDK 설치. with로 버전명, 채널을 설정 가능

[ run : flutter pub get ] 체크아웃으로 가져온 프로젝트가 사용하는 패키지들 설치

음..사실 yaml파일을 내가 한 것보다 더 리팩토링이 가능했다. if문 등을 통해 더 줄일 수 있겠다는 생각이 들었지만 GitHub Action을 처음 하던지라 일단 동작하게끔 만들자는 생각으로 macos에서 실행되는 건 따로 분리를 했다. 우리의 킹갓지피티에게 물어보니 더 줄일 수 있는 것 같다.

CI/CD를 구축해본 적이 없어 GitHub Action 공부를 많이 해야 할 것 같아 좀 걱정이었는데 막상 해보니까 되게 간단하다는 생각이 든다. (물론 CD는 구축하지도 않았지만ㅋㅋ) 역시 뭐든 직접 해봐야 더 잘 알게 되는 것 같다.