s3에 대해 미리 서명 된 URL을 생성 할 수 있어야하는 ec2 인스턴스에 서버 프로그램을 배포하고 있습니다. 지금까지 테스트를 위해 AWS 자격 증명을 환경 변수에 넣었지만 지금은 IAM 역할 전략으로 전환하고 싶습니다. 그러나 역할에 액세스해야하는 정책에 대해서는 확실하지 않습니다. 내 초기 추측은 AmazonS3FullAccess를 갖는 것이지만 설명에 "AWS 관리 콘솔을 통해 모든 버킷에 대한 모든 액세스 권한을 제공"하지만 ec2 인스턴스는 관리 콘솔이 아닌 C++ SDK를 사용하게됩니다. 아니면 정책이 중요하지 않다는 것입니다. 정책이있어 어쨌든 자격 증명을 얻는 것입니까?AWS 어떤 S3에 대한 IAM 역할이 사전 지정된 URL
혼란스러운 정책과 역할이 있습니다.
정책은 사용자, 역할 또는 그룹에 사용 권한을 부여합니다.
사용자와 역할의 차이는 미묘하지만 기본적으로 역할은 AWS의 다른 서비스 (예 : EC2 인스턴스)에서 가정되는 반면 사용자는 일반적으로 AWS에서 사용하기 위해 만든 ID입니다 .
전체 액세스에 대한 정책 설명은 관리 콘솔에 언급 될 수 있지만 콘솔, api 또는 sdk를 통한 모든 버킷에 대한 모든 액세스 권한을 부여합니다. 모두 실제로 마찬가지입니다.
전체 액세스 정책을 사용하면 안됩니다. 이를 실제 정책을 작성하기위한 기반으로 사용할 수 있지만 IAM은 항상 최소한의 권한 원칙을 사용해야합니다. 여기서는 절대적으로 필요한 권한 만 부여합니다.이 경우 역할은 특정 버킷에 대한 읽기 및 가능한 경우 목록 사용 권한 만 필요합니다. 읽는 데 필요한 URL을 생성하는 경우 문제가되거나 업로드를 허용하는 경우 사용 권한을 넣으십시오.
개발 목적으로 AmazonS3FullAccess 정책을 사용자가 만든 역할에 첨부 할 수 있습니다. IAM 역할을 EC2 인스턴스에 연결하면 자격 증명을 내보낼 필요가 없습니다.
그러나 개발 작업이 완료되면 정책을 다시 검토하여보다 제한적으로 만드십시오. 새로운 관리 정책을 만들거나 (AmazonS3FullAccess는 AWS에서 관리되며 사용자는 해당 권한을 업데이트 할 수 없음) 응용 프로그램에 필요한 특정 권한으로 새로운 인라인 정책을 만들 수 있습니다.
이것은 유혹스러운 운명입니다. * 지금 * 올바른 정책을 얻을 시간이 없다면, 무언가를 깨뜨릴 까봐 두려워서 나중에 전체 액세스 권한 *을 제거 할 시간이 없습니다. –
감사! Signing URL 만위한 정책이나 작업이 없었기 때문에 혼란이 시작되었지만 결국에는 s3 : GetObject 및 s3 : PutObject를 수행 할 수있는 정책으로 테스트를 마쳤습니다. 난 당신이 업로드하는 서명 된 URL을 제공 할 것 같아요, 당신은 적어도 자신을 업로드 할 수 있어야합니다 – aspirino67