AWS 에서 IAM Role을 Assume 하기 위해서는 대상 Role의 Trust Relationship에 Assume을 요청하는 Role, User등이 등록되어 있어야 하는데요.
이 때 Trust Relationship에 Policy 설정을 어떻게 할 수 있는지 제일 이해하기 쉽게 설명한 글이 AWS 블로그에 올라와서 공유해요.
1개이상 되는 계정의 Role을 Assume해서 사용하거나, 동일 계정 내에서도 IAM User나 IAM Role이 다른 Role을 Assume해서 사용하는 경우가 꽤 있어서, 이 때 Assume할 수 있는 권한을 어떻게 부여(허가)할 수 있는지 자세히 설명되어 있어 공부에 도움이 되었어요.
EKS 사용하면서 IRSA(IAM Roles for Service Accounts) 도 보통 같이 사용하게 되는데, 이 때에도 물론 Trust Relationship이 등록/사용돼요. 그 과정을 자세히 설명한 ssup2 님의 글. https://ssup2.github.io/theory_analysis/AWS_EKS_Service_Account_IAM_Role
간단한데 생각보다 사람들이 하지 않는 사소한 습관
1️⃣ 내가 맡은 공식, 비공식 업무 및 서류 기록하기
많은 사람들이 하는 큰 착각은 “다른 사람들이 내가 무슨 일 맡은지 아니까”라며 따로 개인 업무 기록를 안한다. 코드 짜기와 서류 및 보고서 작성하기 등등 결과가 확실한 업무라도 업무를 수행하는 과정 중에 세세한 코드 변경이나 작성하는 문서가 생긴다. 결과에 직접적으로 연관되는 모든 서류와 코드는 나중에 쉽게 찾을 수 있도록 한곳에 링크를 모아두자.
그리고 가능하면 모든 것을 문서화 하거나, 보여줄 수... 더 보기
시니어가 될 수 없는 개발자는 어떤 특징을 갖고 있을까요?
관련 글 읽고 정리하면서 제 생각도 함께 올립니다.
1️⃣ 수동적인 사람
수동적인 개발자는 다른 사람과 팀원이 되어 함께 일할 수 있는 스킬이 부족하다. 다른 사람과 의사소통이 제대로 되지 않으면 결국 좋은 성과를 내지 못한다.
2️⃣ 변화를 거절하는 사람
새로운 일에 도전하지 않고 하던 일만 하고 변화를 싫어하는 사람은 성장하지 않는다.
3️⃣ ‘Ownership’이 없는 사람
많은 개발자가 본인 직무 외에 더 많은 일을 떠맡아서 하기도 한다. 반대로 일부러... 더 보기