У меня есть репозиторий S3
, к которому я хочу получить доступ в моем процессе сборки. Он содержит некоторые из зависимостей моего проекта. Мой проект развертывается в экземпляре EC2 с назначенной ролью - Repo_dependent
. Роль имеет Access_Repo
политик, прикрепленный к нему:Получение учетных данных роли AWS в Gradle
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1484560548000",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::my_bucket",
"arn:aws:s3:::my_bucket/*"
]
}
]
}
Когда я раскрываю новый сервер я получаю The AWS Access Key Id you provided does not exist in our records. (Service: Amazon S3; Status Code: 403; Error Code: InvalidAccessKeyId; Request ID: 02169BFDCF7AFE10)
исключение.
Мой сценарий сборки это (сокращенно для простоты)
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.amazonaws:aws-java-sdk:1.11.83'
}
}
import com.amazonaws.auth.*
repositories {
jcenter()
maven {
url "s3://my_bucket.s3.amazonaws.com"
credentials(AwsCredentials) {
def providercreds = new InstanceProfileCredentialsProvider().getCredentials()
accessKey providercreds.getAWSAccessKeyId()
secretKey providercreds.getAWSSecretKey()
}
}
}
Мое предположение, что я что-то не хватает либо как экземпляры EC2 доступа к их роли или что-то в том, как определяются роли. При попытке запустить один и тот же сценарий локально с пользователем, который имеет политику Access_Repo
, и вместо использования InstanceProfileCredentialsProvider
использовать DefaultAWSCredentialsProviderChain
, сборка выполняется нормально. Однако использование DefaultAWSCredentialsProviderChain
и развертывание экземпляра снова привело к тому же исключению.
Любая помощь будет очень оценена.
Update:
Тестирование осуществляется с помощью AWS CLI и используя STSAssumeRoleSessionCredentialsProvider
показывает сценарий сборки использует правильную роль с DefaultAWSCredentialsProviderChain
поставщика. Добавление AmazonS3FullAccess
политики к роли не меняет результата
Я использую Дженкинс, чтобы развернуть код, чтобы мой следующий свинец, что может быть что-то не так там
Update2:
Я попытался захватить сеть трафик, чтобы узнать, какие учетные данные отправлены AWS, и похоже, что разные учетные данные отправляются Gradle и AWS CLI, поэтому я возвращаюсь к своему первоначальному предположению, что Gradle не выполняет правильную роль.
Изучив URL-адрес, я думаю, что вы создали ведро в Северной Вирджинии. Вы можете прокомментировать определение учетных данных в части скрипта сборки. С моей точки зрения, он ищет ключ доступа и секретный ключ в экземпляре EC2 (локальный диск), а не роль IAM. –
Не уверен, что я понимаю .. Если я удалю учетную запись, все будет работать? –
Он должен работать. Код показывает, что он ищет в локальном для aws учетных данных .. –