Mais cedo ou mais tarde uma ferramenta externa pede-lhe "uma chave da AWS": um painel de controlo, um sistema de cópias, um monitor. A tentação é copiar a chave do seu utilizador administrador. Nunca o faça. Quem tiver essa chave pode fazer tudo o que você pode fazer, incluindo apagar a conta inteira. O correto é criar um utilizador IAM à parte com uma política que permita só as ações concretas de que essa ferramenta precisa, e dar-lhe a sua chave.
Vamos fazê-lo a partir do AWS CloudShell, o terminal que vem integrado na consola web, porque são quatro comandos que se copiam e colam e o resultado é exato. Não é preciso instalar nada no seu computador.
Antes de começar: o que significa cada coisa
- IAM
- O serviço da AWS que gere quem pode fazer o quê na sua conta: utilizadores, chaves e permissões.
- Utilizador IAM
- Uma identidade dentro da sua conta da AWS, distinta da sua, à qual dá só as permissões de que precise. Pode ser para uma pessoa ou para um programa.
- Política
- A lista de permissões, escrita num formato de texto chamado JSON: que ações se permitem e sobre o quê. O guia dá-lha feita.
- Chave de acesso
- O "utilizador e palavra-passe" para programas: duas cadeias de texto (identificador e segredo) que uma ferramenta usa para falar com a AWS em nome desse utilizador.
- CloudShell
- Um terminal (ecrã preto onde se escrevem comandos) que vem integrado na consola web da AWS. Não é preciso instalar nada: abre-se e já está ligado à sua conta.
- Permissões mínimas
- A ideia de dar a cada ferramenta só o imprescindível. Se a chave for comprometida, o dano fica limitado a isso.
- ARN
- O nome completo e único de qualquer coisa na AWS, com a forma arn:aws:... Serve para se referir a ela sem equívocos.
- Função (role)
- Uma alternativa ao utilizador com chave: a ferramenta "pede emprestada" uma permissão temporária sem que exista uma palavra-passe permanente. Mais seguro, se a ferramenta o admitir.
Passo a passo
Decida que ações a ferramenta precisa
Antes de escrever o que quer que seja, faça a lista. Um painel que gere máquinas Lightsail precisará, por exemplo, de: ver as máquinas e o seu estado, arrancar, parar e reiniciar, e talvez criar e ver instantâneos. Não precisa de criar nem apagar máquinas, nem de ver a faturação, nem de mexer em utilizadores. Cada ação que não está na lista é uma ação que não vai dar. Se a ferramenta for séria, dir-lhe-á exatamente que permissões pede; se lhe pedir "AdministratorAccess", desconfie.
Abra o CloudShell
Na consola da AWS, clique no ícone de terminal da barra superior (CloudShell) ou procure-o pelo nome. Demora alguns segundos a arrancar. Tem já um terminal Linux com a ferramenta
awsconfigurada com as suas credenciais atuais, por isso tudo o que fizer ali fá-lo como o utilizador com que está na consola (que deve ter permissão para gerir o IAM).Escreva a política
Crie um ficheiro com a política em formato JSON. Este exemplo permite ver, arrancar, parar e reiniciar máquinas Lightsail e gerir os seus instantâneos, nada mais. Cole o bloco inteiro no CloudShell:
cat > politica.json <<'FIN' { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "lightsail:GetInstances", "lightsail:GetInstance", "lightsail:GetInstanceState", "lightsail:GetInstanceMetricData", "lightsail:GetRegions", "lightsail:StartInstance", "lightsail:StopInstance", "lightsail:RebootInstance", "lightsail:GetInstanceSnapshots", "lightsail:GetInstanceSnapshot", "lightsail:CreateInstanceSnapshot", "lightsail:DeleteInstanceSnapshot" ], "Resource": "*" }] } FINCada ação chama-se
servicio:Operación. Se só quiser que a ferramenta veja, retire as linhas de Start, Stop, Reboot, Create e Delete. Para EC2, S3 ou RDS as ações têm outros nomes, mas a mecânica é idêntica. No Lightsail a maioria das ações não pode ser limitada a uma máquina concreta, por isso oResourceé*; no EC2 ou no S3 pode indicar o identificador exato do recurso.Crie a política, o utilizador e junte-os
Três comandos. Mude o nome se quiser, mas que diga para que serve:
aws iam create-policy --policy-name PanelMaquinas --policy-document file://politica.json aws iam create-user --user-name panel-maquinas CUENTA=$(aws sts get-caller-identity --query Account --output text) aws iam attach-user-policy --user-name panel-maquinas \ --policy-arn arn:aws:iam::$CUENTA:policy/PanelMaquinasO primeiro comando devolve o ARN da política; o terceiro reconstrói-o com o número da sua conta para que não tenha de o copiar. Repare que ao utilizador não damos palavra-passe de consola: existirá só para a chave de acesso.
Gere a chave de acesso
aws iam create-access-key --user-name panel-maquinasA resposta traz dois valores:
AccessKeyId(começa por AKIA) eSecretAccessKey. O segredo só é mostrado desta vez. Copie-o diretamente para a ferramenta que o vai usar. Não o cole num e-mail, num chat nem num documento partilhado. Se o perder, não faz mal: apaga essa chave e cria outra.Apague o ficheiro e verifique
rm politica.json aws iam list-attached-user-policies --user-name panel-maquinasDeve aparecer só
PanelMaquinas. Configure a ferramenta com a chave e teste uma ação permitida (ver máquinas) e uma não permitida (criar uma): a segunda deve falhar com "not authorized". Esse erro é a prova de que fez bem o trabalho.
O que pode correr mal
A ferramenta diz que não tem permissão para algo que quer mesmo permitir
Falta-lhe uma ação na política. A mensagem de erro da AWS diz exatamente qual (User ... is not authorized to perform: lightsail:GetBundles). Acrescente-a ao JSON e atualize a política com aws iam create-policy-version --set-as-default, ou edite-a a partir da consola do IAM. Acrescente só essa ação, não volte a abrir a mão.
Colei o segredo num sítio onde não devia
Considere-o comprometido. No CloudShell: aws iam delete-access-key --user-name panel-maquinas --access-key-id AKIA... e crie outra. Como o utilizador tem permissões mínimas, o dano possível era pequeno; é essa a graça de tudo isto.
O terceiro comando falha com o ARN
Pode ser que o seu utilizador de consola não tenha permissão para sts:GetCallerIdentity (raro) ou que o nome da política tenha uma gralha. Copie o ARN que o primeiro comando devolveu e cole-o à mão em --policy-arn.
Não seria melhor uma função do que um utilizador?
Sim, quando a ferramenta o suporta: uma função IAM que a ferramenta assume a partir da sua própria conta da AWS não tem chave que se possa comprometer e as credenciais caducam sozinhas. Pergunte ao seu fornecedor se admite "acesso por função" ou "cross-account role". Se não, o utilizador com permissões mínimas é a segunda melhor opção, e muito melhor do que a chave de administrador.
No Simplio
No Simplio não tem de escrever a política: na ajuda marca com caixas o que quer permitir (só ver, sem firewall, sem terminal, uma região...) e ele gera-lhe o JSON e o script completo para colar no CloudShell, que devolve a chave já feita. E se preferir evitar chaves, o Simplio admite a ligação por função, com credenciais temporárias que caducam numa hora. A chave é guardada encriptada e nunca volta a ser mostrada.
O mesmo, na AWS e no Simplio
| Na consola da AWS | No Simplio | |
|---|---|---|
| Escrever a política | Conhecer o nome exato de cada ação da AWS e o formato JSON | Marcar caixas (só ver, sem firewall, sem terminal, uma região): o JSON gera-se sozinho |
| Criar utilizador, política e chave | CloudShell, 4 comandos, 15 minutos da primeira vez | Colar no CloudShell o script que a ajuda gera: 2 minutos |
| Se não quiser chaves | Desenhar uma função entre contas à mão | Ligação por função com um ARN que o Simplio gera para si |