우선 IAM이란 Identity Access management이다.
즉 식별 접근 제어를 한다는 뜻인데 이걸 어떻게 하느냐?
두 가지 단계를 통해 한다.
Trust policy : 신뢰하는 entity가 누구인가? 위 그림에서 모자가 있는데 이 모자를 쓸 수 있는 그런 역할이 누구인가를 본다.
Permission policy : 모자쓰고 입장했다 하더라도 어디 접근할 수 있는지는 다르다. 그러한 접근과 행동에 대한 정책이 필요하다.
영어로 긴 설명이 되어있는데 몇가지만 짚고 넘어가려고 한다.
우선 Role은 어떠한 행동을 할수 있는 권한을 부여하는 것이며 Long term으로 주어지지 않는다.
아주 잠깐 주어지며 이를 위임할수도 있다.
이러한 접근가능 여부는 정책 파일에 담겨 있고 앞서 말했듯이 Trust와 Permission 두 가지 정책 파일에 담겨 있다.
위의 예시를 보면 아래 resource에 대해서 role을 얻을수 있도록 허락하는 것이다.
이때 account_id_number와 같은 것들이 적혀있는데 이 또한 ARN이라고 볼 수 있다.
Role을 사용할 수 있는 Entity는?
여기서 Role을 사용한다는 것은 서비스를 이용한다는 것이다.
세 가지 IAM사용자, 웹 서비스, 외부 사용자가 있다.
여기서 외부 사용자는 내가 AWS를 사용하고 있는데 구글 ID를 이용해 특정 resouce에 접근하겠다는 것이다.
여기서 한 사용자는 여러 role을 맡을수도 있는데 Role Chaining가 활용 가능하다.
내가 어떤 Role을 가지면 자연스럽게 추가로 또 다른 Role을 가지게 되는 것이다.
내가 컨트롤 가능한 자원에 대해서 누군가에게 권한을 줄 수 있다.
이때 두 가지 policy에 대한 IAM Role을 생성해야 한다.
사용자가 해당 role을 assume 하는 것에 대한 허용과 어떠한 행동을 하겠다는 허용이 포함되어야 한다.
Federation은 연합이라는 뜻인데 예를 들어서 이해해보자
내가 만약 구글관련 서비스 사용하고 있는데 구글에 로그인할때 다른 페이스북과 같은 플랫폼에서 로그인하면 구글 서비스를 받을수 있다라
이때 연합 관계가 되는 것
당연히 federation을 위해선 신뢰관계가 형성이 되야 한다.
- Federated user : 즉 연합된 유저의 경우는 aws를 사용할떄 구글의 id를 연동한다면 구글의 id가 federated user라고 함
- Trust policy : assume 할 수 사람인지 보는것으로 Json format으로 되어 있다.
앞에서 했던 내용이지만..
Permission Policy : 특정 Resouce에 대해 어떤 action을 취할 수 있느냐
Permission Boundary : 어떤 것까지의 permission까지만 가능하다 (너의 role에 대해선)
Principal은 Subject(id, entity)을 부르는 또 다른 말이다.
다시 첫 내용으로 돌아가서 보면 정책과 role에 대해서는 이제 어느 정도 알았다.
이 Role에 접근하기 위해서는 토큰이 필요하다.
이 토큰을 받기 위한 것이 STS(Security Token service)이다.
AWS에서의 role적용을 위한 순서는 위와 같다.
1번에서 우선 S3 Bucket(=DB)에 접근할수 있는 role을 만든다
2번에서 개발자는 Role을 가지는 Application을 만들고 여기에 1번에서 만들었던 role 정책을 할당한다
3번에서 사용자는 인스턴스에서 해당 Role을 충족하면 권한 얻는다.
4번에서는 해당 권한을 통해 S3 Bucket(=DB)에 접근한다.
그 안의 Role파일은 위와 같이 작성된다.
자세히 보면 총 세 가지 파일인데 Trust policy를 통해서 " 이 주체가 지금 Role을 얻기 위해 접근을 하고 있는데 그 주체에 대해서 허락이다"
이후 my-iot-role파일을 보니 얻고자 하는 Role에 대한 설명이 적혀있다.
그리고 trust 파일에서 어느 파일에 접근이 가능한지 적혀있다.
