0
Spinnaker에서 AMI를 구워 AWS 자동 확장 그룹에 배포하려고합니다. 문제는 인스턴스에 too many permissions이 필요하다는 것입니다. Spinnaker blog post에 명시된 바와 같이 (예 : "오늘날의 환경에서는 도구를 사용하여 환경에 전체 액세스 권한을 부여하는 것은 좋지 않은 행동으로 간주됩니다.), spinnaker 인스턴스 사용 권한을 제한하는 방법이 있는지 알고 싶지만 사용자가 응용 프로그램을 자신의 클러스터에 AWS에서 승인 된 경우Spinnaker 사용자 권한 부여 및 인스턴스 사용 권한 제한
물론, 의사는 애플리케이션에 대한 액세스를 제한 할 수 있다고 말하고 있지만 충분합니까? 애플리케이션 A의 멤버가 (예 : 파이프 라인 단계에서) Spinnaker의 허가를 받아 AWS API를 어떻게 든 호출 할 수 있습니까? (그러므로 응용 프로그램 B의 클러스터를 수정할 수 있음). Spinnaker 인스턴스에 대한 SSH 액세스가 이미 비활성화되었다고 가정 해 봅시다.
"god mode"/ 지원 파이프 라인 실행자의 자격 증명에서 전환 할 계획이 있습니까? 현재의 사례를 지원하기 위해 팀은 여전히 하나의 공유 된 AWS 계정에 앱을 배포합니다. 누가 변경 사항을 언제 대시 보드에서 볼 수 있는지, AWS의 경우에는 CloudTrail을 추적 할 수 있어야합니다. "사용자 A가 ASG X를 수정합니다."와 같은 것을 볼 수 있기를 바랍니다. 내 현재의 해킹은 각 개발자의 노트북에서 spinnaker를 실행하는 것입니다. –
지금은 아니지만 제안은 열려 있습니다. 문제는 일반적으로 모든 클라우드 공급자가 IAM/RBAC 보안 모델을 가지고있는 것은 아닙니다. Spinnaker의 캐싱 에이전트가 읽기 전용 자격 증명을 사용하고 적절한 경우 최종 사용자 자격 증명이 사용되는 것이 이상적입니다. 우리는 클라우드 공급자로부터 최종 사용자 자격 증명을 가져오고 안전하게 저장하는 방법을 찾아야합니다. 그런 다음 우리는 파이프 라인을 자동으로 트리거하는 역할을 질문해야합니다. 불투명 한 답변으로 털이 많은 문제입니다. –