[GCP] 클라우드 IAM의 개념을 정리해봤습니다.

6417 단어 GCPIAMcloudiamtech

개시하다


IAM을 만지면서 "역할과 정책의 관계가 뭐였더라?""서비스 계정이 뭐였더라?"매번 조사할 때마다 분위기에 따라 사용했다.
이번에는 클라우드 IAM을 다시 공부했습니다.

클라우드 IAM이란?


Cloud IAM은 "누구(ID)"가 "어떤 자원", "어떤 접근권(역할)"에 대해 정의하여 접근 제어를 관리할 수 있습니다.
예를 들어 다음과 같이 설정하여 적절한 가속 관리를 할 수 있다.
  • 개발자 A의 Cloud Function 및 Pub Sub 열람 및 편집 가능
  • "Cloud Function의 함수 A"는 "Cloud Stage"의 "만들기
  • 만 수행할 수 있습니다.

    클라우드 IAM의 개념


    공식 문서에는 정확하고 상세한 설명이 있으니 참고하세요.
    https://cloud.google.com/iam/docs/overview?hl=ja#concepts_related_identity
    여기서 자신이 이해한 것을 떼어 설명한다.
    먼저 이미지맵입니다.

    등장인물은 구성원, 캐릭터, 권한 세 가지가 있다.
    구성원은 여러 역할을 가질 수 있고, 역할은 하나 이상의 권한을 가질 수 있습니다.구성원에게는 직접적인 권한이 없다.

    권한


    자원에 대해 어떤 조작을 할 수 있는지 나타낸다.
    사용자가 편집하지 않는 등 GCP에 권한이 미리 준비되어 있습니다.
    예를 들어 Cloud Function 권한에는 이런 권한이 있습니다.이 권한에 따라 구성원이 자원에 접근할 수 있는지 여부를 결정합니다.

    이른바 배역


    역할은 권한을 총결한 것이다.
    캐릭터는 세 가지 유형이 있다.

  • 기본 롤러
    IAM 이전에 존재했던 소유자, 편집자, 열람자의 역할을 도입한다.
    Google Cloud에 적용되는 모든 서비스 때문에 정식 사용 환경에는 적합하지 않습니다.

  • 미리 정의된 역할
    GCP가 미리 준비한 역할입니다.App Engine 볼륨, Pub/Sub 볼륨 등의 서비스가 있습니다.
    베타 버전의 물건은 호환성을 보장할 수 없기 때문에 정식 환경에서 사용할 때 주의해야 한다.
    또 새로운 기능과 서비스 등이 추가되면 필요에 따라 권한이 자동으로 업데이트된다.
  • 맞춤형 롤러
    사용자 지정 역할은 사용자가 만든 역할입니다.
    더 자세한 권한 관리를 할 수 있기 때문에 최소 권한의 원칙을 적용할 수 있다.
    다음 그림은 캐릭터의 제작 화면이다.캐릭터를 만들 수 있는 권한을 자유롭게 선택할 수 있습니다.

  • 소위 구성원


    자원에 대한 접근 제어의 대상이 되다.누구?
    구성원에는 다음과 같은 유형이 있습니다.
  • Google 계정
    Google 계정과 연결된 개인 메일 주소
  • 서비스 계정
    개인이 아닌 응용 프로그램에서 사용하는 계정입니다.
    예를 들어, Cloud Function을 만들 때 서비스 계정을 지정합니다.

  • Google 그룹
    여러 Google 계정 및 서비스 계정 취합
  • Google Workspace 도메인
    조직의 Google Workspace 계정에서 생성된 모든 Google 계정을 나타내는 가상 그룹
  • Cloud Identity 도메인
    조직의 모든 Google 계정을 나타내는 가상 그룹
  • 모든 인증된 사용자
    모든 서비스 계정 및 Google 계정을 통해 인증된 모든 사용자를 나타냅니다
  • .
  • 모든 사용자
    인증 사용자와 미인증 사용자를 포함한 인터넷 사용자를 표시한다
  • 더 자세히 알고 싶으면 여기.부터 확인하세요.

    정책 및 바인딩


    클라우드 IAM에도 정책과 바인딩이라는 개념이 있다.
    그림은 아래와 같다.

    구성원 및 역할에 대한 링크를 바인딩이라고 하고 이를 요약하여 정책이라고 합니다.
    한 명 이상의 구성원을 한 작용에 귀속시키다.メンバー:ロール = 多:1의 관계.
    Cloud IAM은 구성원이 개체 리소스에 대한 권한을 가지고 있는지 정책적으로 조사합니다.
    콘솔을 사용해 멤버를 만들 때는'전략'과'바인딩'을 명확하게 만들지 않아 이해하기 어렵다.
    실제로 다음 두 개의 바인딩을 생성한 경우:.
    또한 귀속에 조건을 추가할 수 있으며 날짜와 시간대를 지정할 수도 있고 자원 이름을 비교할 수도 있습니다.

    나는 정책과 귀속의 실제 데이터 구조를 확인하는 것이 가장 이해하기 쉽다고 생각한다.
    다음 명령을 통해 정책 목록을 얻을 수 있습니다.gcloud projects get-iam-policy ${PROJECT_ID} --format json이렇게 되면 아래 대상은 반환됩니다.
    구조를 확인한 후 전략은 전체 대상이고 그 중에서 bindings이 있다.bindings 중에rolemembers가 있어 일대다의 관계임을 알 수 있다.
    {
      "bindings": [
        {
          "members": [
            "serviceAccount:aaaa.gserviceaccount.com",
            "serviceAccount:[email protected]"
          ],
          "role": "roles/editor"
        },
        {
          "members": [
            "user:[email protected]"
          ],
          "role": "roles/owner"
        },
      ],
      "etag": "AAA-BvS0zfw=",
      "version": 1
    }
    

    끝말


    이번에는 클라우드 IAM을 배웠지만, 역할과 정책 등은 AWS의 IAM과 개념이 달라 주의가 필요하다.(현장에서도 같은 방법을 썼지만 대화가 충돌하지 않았는지...)
    또 AWS IAM 보도가 많았고, 클라우드 IAM 보도는 아직 드물었다.

    인용하다


    https://www.isoroot.jp/blog/1244/
    https://qiita.com/os1ma/items/df01080dfa81c185357e

    좋은 웹페이지 즐겨찾기