У меня есть сценарий оболочки, который должен загружать некоторые файлы с S3 и монтировать диск ebs. Тем не менее, я всегда получаю "Невозможно найти учетные данные".
Я указал свои учетные данные командой aws configure а команды работают вне сценария оболочки. Может ли кто-нибудь, пожалуйста, сказать мне (желательно подробно), как заставить его работать?
Это мой сценарий
#!/bin/bash
AWS_CONFIG_FILE="~/.aws/config"
echo $1
sudo mkfs -t ext4 $1
sudo mkdir /s3-backup-test
sudo chmod -R ugo+rw /s3-backup-test
sudo mount $1 /s3-backup-test
sudo aws s3 sync s3://backup-test-s3 /s3-backup/test
du -h /s3-backup-test
ipt (short version):
Спасибо за любую помощь!
sudo изменит каталог $HOME (и, следовательно, ~) на /root и удалит большинство переменных bash, таких как AWS_CONFIG_FILE, из среды. Убедитесь, что вы делаете все с помощью aws как root или как ваш пользователь, не смешивайте.
Убедитесь, что вы сделали sudo aws configure например. И попробовать
sudo bash -c 'AWS_CONFIG_FILE=/root/.aws/config aws s3 sync s3://backup-test-s3 /s3-backup/test'
Возможно, вы захотите удалить все sudo изнутри скрипта и просто sudo сам скрипт.
Это не обязательно связано с исходным вопросом, но я натолкнулся на это, когда искал соответствующую проблему, поэтому я собираюсь написать ее на случай, если она может помочь кому-то еще. Я настроил aws на конкретного пользователя и протестировал его с помощью sudo -H -u thatuser aws..., но он не работал с awscli 1.2.9, установленным на Ubuntu 14.04:
% sudo -H -u thatuser aws configure list
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key <not set> None None
secret_key <not set> None None
region us-east-1 config_file ~/.aws/config
Мне пришлось обновить его, используя pip install awscli, в котором были pip install awscli новые версии awscli (1.11.93), boto и множество других вещей (awscli docutils botocore rsa s3transfer jmespath python-dateutil pyasn1), но это привело к вещам начиная работать правильно:
% sudo -H -u thatuser aws configure list
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************WXYZ shared-credentials-file
secret_key ****************wxyz shared-credentials-file
region us-east-1 config-file ~/.aws/config
Хотя у вас могут быть ваши учетные данные и файл конфигурации правильно расположенными в ~/.aws, он может не попасть в вашу учетную запись пользователя.
Запустите эту команду, чтобы проверить, установлены ли ваши учетные данные: aws configure list
Чтобы установить учетные данные, запустите эту команду: aws configure и введите учетные данные, указанные в файле ~/.aws/credentials.
Ответ на случай, если кто-то наткнется на это, основываясь на названии вопроса.
У меня была та же проблема, когда по сообщениям CLI AWS unable to locate credentials.
Я удалил набор учетных credentials [default] из своего файла credentials как не использовал их и не думал, что они необходимы. Кажется, что они есть.
Я тогда преобразовал свой файл следующим образом, и это работало...
[default]
aws_access_key_id=****
aws_secret_access_key=****
region=eu-west-2
[deployment-profile]
aws_access_key_id=****
aws_secret_access_key=****
region=eu-west-2
Глупый и предостерегающий хвост ржавого стропальщика:
Я определил переменную HOME в своем скрипте как место, где скрипт должен идти для построения платформы.
Эта переменная перезаписала env var, которая определяет пользователей оболочки $HOME. Таким образом, команда AWS не смогла найти ~/.aws/credentials поскольку ~ ссылался не на то место.
Ненавижу это признавать, но надеюсь, что это поможет кому-то сэкономить время.
Если вы используете файл .aws/config с ролями, убедитесь, что ваш файл конфигурации правильно отформатирован. В моем случае я забыл поставить role_arn = перед arn. Профиль по умолчанию находится в .aws/credentials и содержит идентификатор ключа доступа и секретный ключ доступа идентификатора iam.
Файл конфигурации содержит детали роли:
[profile myrole]
role_arn = arn:aws:iam::123456789012:role/My-Role
source_profile = default
mfa_serial = arn:aws:iam::987654321098:mfa/my-iam-identity
region=ap-southeast-2
Вы можете быстро проверить доступ, позвонив
aws sts get-caller-identity --profile myrole
Если у вас включен MFA, как у меня, вам нужно будет ввести его при появлении запроса.
Enter MFA code for arn:aws:iam::987654321098:mfa/my-iam-identity:
{
"UserId": "ARABCDEFGHIJKLMNOPQRST:botocore-session-15441234567",
"Account": "123456789012",
"Arn": "arn:aws:sts::123456789012:assumed-role/My-Role/botocore-session-15441234567"
}
Эта ошибка возникала сегодня при запуске aws cli на EC2. В моих ситуациях я мог получить информацию об учетных данных при запуске aws configure list. Однако я работаю в корпоративной среде, которая требует таких вещей, как aws kms decrypt, PROXY. Как только я настрою прокси, информация об учетных данных aws исчезнет.
export HTTP_PROXY=aws-proxy-qa.cloud.myCompany.com:8099
export HTTPS_PROXY=aws-proxy-qa.cloud.myCompany.com:8099
Оказывается, мне также нужно установить NO_PROXY и иметь адрес метаданных ec2 в списке 169.254.169.254. Кроме того, поскольку вы должны проходить через конечную точку s3, у вас также должно быть .amazonaws.com в no_proxy.
export NO_PROXY=169.254.169.254,.amazonaws.com
Я столкнулся с этим, пытаясь запустить команду aws-cli из root cron.
Поскольку учетные данные хранятся в $ HOME/.aws/credentials, а я инициализировал aws-cli через sudo, $ HOME по-прежнему/home/user/. При запуске из cron $ HOME - это /root/, поэтому cron не может найти файл.
Исправление состояло в том, чтобы изменить $ HOME для конкретной работы cron. Пример:
00 12 * * * HOME=/home/user aws s3 sync s3://...
(в качестве альтернативы можно переместить, скопировать или создать символическую ссылку .aws dir из /home/user/в /root/)