Qual é o melhor método para passar AWS credenciais como os dados do usuário a uma instância EC2?

StackOverflow https://stackoverflow.com/questions/640838

Pergunta

Eu tenho uma arquitetura de processamento de trabalho com base na AWS que requer EC2 instâncias de consulta S3 e SQS. A fim pelas instâncias a correr para ter acesso à API as credenciais são enviadas como dados do usuário (-f) na forma de um script shell base64 codificado. Por exemplo: 

$ cat ec2.sh
...
export AWS_ACCOUNT_NUMBER='1111-1111-1111'
export AWS_ACCESS_KEY_ID='0x0x0x0x0x0x0x0x0x0'
...
$ zip -P 'secret-password' ec2.sh
$ openssl enc -base64 -in ec2.zip

Muitos casos são lançados ... 

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

Cada decodificações de instância e decifra ec2.zip usando o 'segredo-password' que é embutida em um script de inicialização. Apesar de não trabalho, tenho duas questões com a minha abordagem.

  1. '-P zip' não é muito seguro
  2. A senha é codificado na instância (é sempre 'segredo-password')

O método é muito semelhante ao descrito aqui

Existe uma abordagem mais elegante ou aceite? Usando gpg para criptografar as credenciais e armazenar a chave privada na instância para decifrá-lo é uma abordagem que eu estou pensando agora, mas eu sou conhecimento de quaisquer ressalvas. Posso usar os pares de chaves AWS diretamente? Estou faltando alguma parte óbvia de super da API?

Foi útil?

Solução

Você pode armazenar as credenciais da máquina (ou transferência, utilização, em seguida, removê-los.)

Você pode transferir as credenciais mais de um canal seguro (por exemplo, usando scp com par de chaves de autenticação não-interativo, por exemplo), de modo que você não precisa realizar qualquer criptografia personalizado (apenas certifique-se de que as permissões estão devidamente definido para 0400 na chave arquivo em todos os momentos, por exemplo, definir as permissões nos arquivos mestre e uso scp -p)

Se o acima não responder à sua pergunta, por favor, fornecer detalhes mais específicos re. o que sua configuração é eo que você está tentando alcançar. São EC2 ações a serem iniciadas em vários nós de um local central? SSH está disponível entre os vários nós e a localização central? Etc.

Editar

Você considerou parametrização seu AMI , exigindo aqueles que instancia seu AMI a primeira preencher os dados do usuário (ec2-run-instances -f user-data-file) com chaves de suas AWS? Seu AMI pode recuperar dinamicamente esses parâmetros por instância de http://169.254.169.254/1.0/user-data.

Atualizar

OK, aqui vai uma comparação das diversas abordagens de segurança de espírito discutido até agora:

  1. Segurança de dados quando armazenado na AMI user-data sem criptografia
    • baixo
    • dados em texto claro é acessível a qualquer user que consegue se conectar à AMI e tem acesso a telnet, curl, wget, etc. (pode acessar http://169.254.169.254/1.0/user-data-texto claro)
    • você está vulnerável a ataques pedido de proxy (por exemplo atacante pede ao Apache que podem ou não podem estar em execução no AMI para obter e encaminhar a http://169.254.169.254/1.0/user-data-texto claro)
  2. Segurança de dados quando armazenado no user-data AMI e criptografado (ou decryptable) com chave de fácil obtenção
    • baixo
    • chave facilmente obtidos (password) pode incluir:
      • chave codificados num script de dentro de um ABI (onde o ABI podem ser obtidos por um invasor)
      • chave codificada em um script no próprio AMI, onde o script é lido pelo qualquer user que consegue se conectar à AMI
      • qualquer outra informação de fácil obtenção, como chaves públicas, etc.
      • qualquer chave privada (a sua chave pública pode ser facilmente obtidos)
    • dada uma chave facilmente obtidos (senha), os mesmos problemas identificados no ponto 1 são aplicáveis, a saber:
      • os dados descriptografados é acessível a qualquer user que consegue se conectar à AMI e tem acesso a telnet, curl, wget, etc. (pode acessar http://169.254.169.254/1.0/user-data-texto claro)
      • você está vulnerável a ataques pedido de proxy (por exemplo atacante pede ao Apache que podem ou não podem estar em execução no AMI para obter e encaminhar a http://169.254.169.254/1.0/user-data criptografado, ulteriorly descrypted com a chave facilmente obtidas)
  3. Segurança de dados quando armazenado no user-data AMI e criptografado com não key facilmente obtidos
    • média
    • os dados criptografados é acessível a qualquer user que consegue se conectar à AMI e tem acesso a telnet, curl, wget, etc. (pode acessar http://169.254.169.254/1.0/user-data criptografada)
      • uma tentativa de descriptografar os dados criptografados podem ser feitas usando ataques de força bruta
  4. Segurança de dados quando armazenado no AMI, em um local seguro (qualquer valor acrescentado para que possa ser criptografada)
    • maior
    • os dados só é acessível a um usuário, o usuário que requer os dados a fim de operar
      • por exemplo. arquivo de propriedade de usuário: o usuário com máscara 0600 ou 0400
    • invasor deve ser capaz de representar o usuário em particular, a fim de ter acesso aos dados
      • camadas de segurança adicionais, tais como negando o utilizador directo log-on (ter de passar através root para representação interactivo) melhora a segurança

Assim, qualquer método que envolve a user-data AMI não é o mais seguro, porque ter acesso a qualquer usuário na máquina (ponto mais fraco) compromete os dados.

Esta poderia ser atenuada se as credenciais S3 só foram necessários para um período limitado de tempo (ou seja, somente durante o processo de implantação), se AWS permitiu-lhe para substituir ou remover o conteúdo do user-data quando feito com ele (mas isso não parece ser o caso.) Uma alternativa seria a criação de credenciais S3 temporários para a duração do processo de implantação, se possível (comprometer essas credenciais, a partir user-data, após o processo de implantação está concluída eo credenciais foram invalidados com AWS, já não representa uma ameaça à segurança.)

Se o acima não é aplicável (por exemplo credenciais S3 necessários por nós implantados indefinidamente) ou não possível (por exemplo, não pode emitir credenciais S3 temporárias para única implantação), então o melhor método continua a morder a bala e scp as credenciais para os vários nós , possivelmente em paralelo, com a propriedade e as permissões corretas.

Outras dicas

Eu escrevi um artigo examinando vários métodos de passar segredos a uma instância EC2 segurança e os prós e contras de cada um.

http: // www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html

A melhor maneira é usar perfis de instância . A idéia básica é:

  • Criar um perfil de instância
  • Criar um novo papel IAM

  • Atribuir uma política para o papel previamente criada, por exemplo:

    { "Declaração": [ { "Sid": "Stmt1369049349504", "Acção": "sqs: ", "Effect": "Permitir", "Recurso": "" } ] }

  • Associar o papel eo perfil da instância juntos.

  • Quando você inicia uma nova instância EC2, certifique-se de fornecer o nome do perfil de instância.

Se tudo funciona bem, e a biblioteca que você usa para se conectar a serviços da AWS a partir de dentro de seus EC2 instância suportes recuperar as credenciais dos meta-dados de instância, o seu código será capaz de usar os serviços da AWS.

Um exemplo completo tomadas a partir da lista do usuário boto de discussão:

Em primeiro lugar, você tem que criar um documento de política JSON que representa o que os serviços e recursos o papel IAM deve ter acesso. por exemplo, esta política concede todas as ações S3 para o balde "my_bucket". Você pode usar qualquer política é apropriado para a sua aplicação. 

BUCKET_POLICY = """{
  "Statement":[{
    "Effect":"Allow",
    "Action":["s3:*"],
    "Resource":["arn:aws:s3:::my_bucket"]}]}"""

Em seguida, você precisa criar um perfil Instância no IAM. 

import boto
c = boto.connect_iam()
instance_profile = c.create_instance_profile('myinstanceprofile')

Depois de ter o perfil de instância, você precisa criar o papel, adicionar a função ao perfil de instância e associar a política com a função. 

role = c.create_role('myrole')
c.add_role_to_instance_profile('myinstanceprofile', 'myrole')
c.put_role_policy('myrole', 'mypolicy', BUCKET_POLICY)

Agora, você pode usar esse perfil exemplo, quando você iniciar uma instância: 

ec2 = boto.connect_ec2()
ec2.run_instances('ami-xxxxxxx', ..., instance_profile_name='myinstanceprofile')

Eu gostaria de salientar que não é necessário para fornecer quaisquer credenciais para sua instância EC2 mais. Usando IAM, você pode criar um papel para as suas instâncias EC2. Nessas funções, você pode definir políticas de grão-finas que permitem que sua instância EC2 para, por exemplo, obter um objeto específico a partir de um S3 balde específica e não mais. Você pode ler mais sobre as Funções do IAM nos docs AWS:

http://docs.aws.amazon.com/IAM/ latest / UserGuide / WorkingWithRoles.html

Tal como outros já apontaram aqui, você realmente não precisa armazenar AWS credenciais para uma instância EC2, usando Roles IAM - https: // AWS .amazon.com / blogs / segurança / a-seguro-way-to-distribuem-AWS-credenciais-to-ec2 / . Acrescento que você pode empregar o mesmo método também para guardar os credenciais NON-AWS para você EC2 instância, como por exemplo, se você tem algumas credenciais db que você deseja manter seguro. Você salvar as credenciais não-AWS em um S3 Bukcet, e usar papel IAM para acessar esse balde. você pode encontrar informações mais detalhadas sobre isso aqui - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top