Hdfs для s3 Distcp - ключи доступа
Для копирования файла из HDFS в корзину S3 я использовал команду
hadoop distcp -Dfs.s3a.access.key=ACCESS_KEY_HERE\
-Dfs.s3a.secret.key=SECRET_KEY_HERE /path/in/hdfs s3a:/BUCKET NAME
Но здесь видны ключ доступа и секретный ключ, которые не защищены. Есть ли способ предоставить учетные данные из файла. Я не хочу редактировать конфигурационный файл, который является одним из методов, с которыми я столкнулся.
4 ответа
Последние версии (2.8+) позволяют скрывать ваши учетные данные в файле jceks; там есть некоторая документация на странице Hadoop s3. Таким образом: нет необходимости помещать какие-либо секреты в командную строку вообще; вы просто делитесь ими в кластере, а затем в команде distcp задаете hadoop.security.credential.provider.path
на путь, как jceks://hdfs@nn1.example.com:9001/user/backup/s3.jceks
Вентилятор: если вы работаете в EC2, учетные данные роли IAM должны автоматически выбираться из цепочки поставщиков учетных данных по умолчанию: после поиска параметров конфигурации и параметров env, он пытается получить GET конечной точки http EC2, которая обслуживает сеанс полномочия. Если этого не происходит, убедитесь, что com.amazonaws.auth.InstanceProfileCredentialsProvider
находится в списке поставщиков учетных данных. Это немного медленнее, чем другие (и может быть задушен), поэтому лучше положить ближе к концу.
Я также столкнулся с той же ситуацией, и после того, как получил временные учетные данные от экземпляра метаданных. (если вы используете учетные данные пользователя IAM, обратите внимание, что упомянутые здесь временные учетные данные - это роль IAM, которая привязана к серверу EC2, а не к человеку, см. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)
Я нашел только указав учетные данные в hadoop distcp
CMD не будет работать. Вы также должны указать конфиг fs.s3a.aws.credentials.provider
, (см. http://hortonworks.github.io/hdp-aws/s3-security/index.html)
Окончательная команда будет выглядеть ниже
hadoop distcp -Dfs.s3a.aws.credentials.provider="org.apache.hadoop.fs.s3a.TemporaryAWSCredentialsProvider" -Dfs.s3a.access.key="{AccessKeyId}" -Dfs.s3a.secret.key="{SecretAccessKey}" -Dfs.s3a.session.token="{SessionToken}" s3a://bucket/prefix/file /path/on/hdfs
Amazon позволяет создавать временные учетные данные, которые вы можете получить по http://169.254.169.254/latest/meta-data/iam/security-credentials/
ты можешь читать оттуда
Приложение в экземпляре получает учетные данные безопасности, предоставленные ролью, из элемента метаданных экземпляра iam / security-credentials / role-name. Приложению предоставляются разрешения для действий и ресурсов, которые вы определили для роли с помощью учетных данных безопасности, связанных с этой ролью. Эти учетные данные являются временными, и мы автоматически их чередуем. Мы делаем новые учетные данные доступными по крайней мере за пять минут до истечения срока действия старых учетных данных.
Следующая команда возвращает учетные данные безопасности для роли IAM с именем s3access.
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access
Ниже приведен пример вывода.
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "AKIAIOSFODNN7EXAMPLE",
"SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"Token" : "token",
"Expiration" : "2012-04-27T22:39:16Z"
}
Для приложений, команд AWS CLI и команд Tools for Windows PowerShell, которые выполняются на экземпляре, нет необходимости явно получать временные учетные данные безопасности - AWS SDK, AWS CLI и Tools для Windows PowerShell автоматически получают учетные данные из экземпляра EC2 сервис метаданных и их использование. Чтобы выполнить вызов вне экземпляра с использованием временных учетных данных безопасности (например, для проверки политик IAM), необходимо предоставить ключ доступа, секретный ключ и токен сеанса. Дополнительные сведения см. В разделе " Использование временных учетных данных безопасности для запроса доступа к ресурсам AWS" в Руководстве пользователя IAM.
Не уверен, что это из-за разницы в версиях, но для использования "секретов от поставщиков учетных данных" -Dfs
флаг мне не подошел, пришлось использовать -D
флаг, как показано в документации hadoop версии 3.1.3 "Using_secrets_from_credential_providers".
Сначала я сохранил свои учетные данные AWS S3 в файле хранилища ключей расширения криптографии Java (JCEKS).
hadoop credential create fs.s3a.access.key \
-provider jceks://hdfs/user/$USER/s3.jceks \
-value <my_AWS_ACCESS_KEY>
hadoop credential create fs.s3a.secret.key \
-provider jceks://hdfs/user/$USER/s3.jceks \
-value <my_AWS_SECRET_KEY>
Тогда следующие distcp
формат команды работал у меня.
hadoop distcp \
-D hadoop.security.credential.provider.path=jceks://hdfs/user/$USER/s3.jceks \
/hdfs_folder/myfolder \
s3a://bucket/myfolder
Если вы не хотите использовать доступ и секретный ключ (или показывать их в своих скриптах) и если ваш экземпляр EC2 имеет доступ к S3, то вы можете использовать учетные данные экземпляра
hadoop distcp \
-Dfs.s3a.aws.credentials.provider="com.amazonaws.auth.InstanceProfileCredentialsProvider" \
/hdfs_folder/myfolder \
s3a://bucket/myfolder