Amazon API Gateway: integrando e protegendo serviços

Primeira API - Apresentação

Olá, eu sou Leonardo Sartorello e te dou as boas-vindas a este curso na Alura.

Audiodescrição: Leonardo se identifica como um homem branco. Tem olhos azuis, cabelo e barba castanhos. Está com uma camiseta preta. Ao fundo, uma estante com decorações em um ambiente iluminado em degradê do vermelho até o azul.

Neste curso, vamos falar sobre API Gateway, um serviço da AWS para que você possa montar APIs de forma rápida e sem servidores.

E para quem é esse curso? Este curso é para você que está avançando nos seus estudos de Cloud e AWS ou para você que já trabalha com a AWS, mas ainda não conhece o API Gateway.

O que vamos aprender?

Neste curso, você vai entender como:

• criar uma API sem servidores na AWS;
• utilizar um banco de dados para armazenar informações relevantes para a API;
• automatizar a inserção de informações dentro do banco de dados através de uma função lambda;
• proteger a API com senha, prevenindo que pessoas acessem a área administrativa da API.

Pré-requisitos

E o que você precisa saber para poder acompanhar este curso? Você precisa ter conhecimento de Cloud e AWS, bem como conhecer um pouco da parte de permissões e redes. Na parte de redes, principalmente as requisições HTTP.

Lembre-se de aproveitar os recursos que a plataforma te oferece, pois além dos vídeos, temos atividades extras, o apoio do fórum e a comunidade do Discord da Alura.

Então, você se animou? Vamos lá!

Primeira API - Planejamento

Antes de começar a explorar o que vamos criar e o serviço que vamos utilizar, precisamos fazer um planejamento. Vamos organizar tudo para conhecer exatamente o nosso passo a passo.

Planejamento

Estamos em uma equipe de DevOps e recebemos um pedido da equipe de Front-end para salvar algumas imagens na AWS. Podemos criar diversos métodos diferentes para isso, mas, para acelerar nosso trabalho, sugerimos utilizar o API Gateway. Dentro dele, vamos criar uma API para facilitar o acesso da equipe de Front-end à AWS.

Outra questão importante: onde serão salvas essas imagens que a equipe deseja armazenar? Podemos usar outro serviço da AWS, o S3, que é um serviço onde podemos guardar imagens e arquivos sem nos preocuparmos com servidores.

Vamos entender como funciona essa API, como ela vai operar e qual será a sua estrutura. A equipe de Front-end vai acessar diretamente a API, subindo as imagens e a API guarda tudo no bucket do S3. O bucket (balde) é o nome da pasta que temos no S3.

Mas, por que a equipe de Front-end não acessa diretamente o bucket? Temos alguns motivos para isso.

Vantagens de usar uma API

Primeiro, a questão de segurança. Se a equipe de Front-end for acessar diretamente o bucket, precisaremos criar usuários para cada pessoa que vai acessar essa função da AWS. E essas pessoas terão acesso completo. Assim, corremos o risco de algum desses usuários ter o login e a senha vazados, o que pode gerar um problema de segurança na AWS.

Além disso, a interface do S3 está sempre mudando. A AWS faz atualizações de interface constantemente. Portanto, a API torna tudo isso um pouco mais fácil para a equipe. Uma vez que você aprendeu a usar, não mudará.

Essas são as vantagens em criar uma API para acessar o S3.

Vale lembrar que a AWS adora atualizar as interfaces. Portanto, pode ser que algum botão ou algo que vamos criar possa mudar de lugar. Mas todas as opções continuarão disponíveis, às vezes em um lugar um pouco diferente.

E também, já vou adiantar uma informação para vocês. A equipe de Front-end, junto com a equipe de Dev, já estão pensando em uma mudança para essa API. Então, talvez ela apareça no meio do curso.

Agora, vamos criar essa API?

Primeira API - Mexendo com políticas e cargos

Agora que já temos um planejamento e sabemos tudo o que precisaremos criar, vamos começar realmente a trabalhar com a AWS e criar todos os recursos.

Para isso, sugerimos comecemos pelo S3, que é onde serão armazenadas todas as imagens que a equipe de front-end vai inserir. Nossa API vai interagir com ele.

Criando bucket no S3

Na parte superior da página inicial do console da AWS, vamos clicar na barra de pesquisa ou usar o atalho "Alt + S" para acessá-la. Basta digitar "S3" e clicar, dentro de Services (Serviços em português), na opção do S3.

Descendo um pouco a tela na área do S3, temos uma seção de "Buckets de uso geral", que é o tipo de buckets que vamos criar. Por isso, clicaremos em um botão laranja escrito "Criar Bucket" logo à direita para entrar na parte de criação dos buckets.

A primeira configuração que a AWS solicita é a região em que vamos criar esse bucket.

Precisaremos criar todos os nossos recursos em uma mesma região. Ou seja, o bucket, a API e qualquer outro recurso criado devem estar sempre na mesma região.

Além disso, se você tem uma aplicação que precisa responder muito rápido para as pessoas usuárias, é importante selecionar uma região que esteja fisicamente próxima delas.

Por exemplo, estamos na América do Sul. Se temos uma aplicação que precisa responder rápido, é interessante escolher o datacenter da AWS com a região disponibilizada da América do Sul (sa-east-1). Com isso, a distância que a informação tem que percorrer é menor e ela chega mais rápido.

No nosso caso, vamos manter no leste dos Estados Unidos, porque é mais barato e também vai nos permitir utilizar o tier gratuito que a AWS fornece. Então, vamos manter tudo que criarmos no us-east-1, que é o Norte da Virgínia.

Temos dois tipos de buckets diferentes: o de propósito geral e o bucket de diretório. No nosso caso, vamos usar o propósito geral, pois ele já vai ser suficiente, além de estar no tier gratuito. Não precisamos do diretório.

O bucket de diretório tem algumas vantagens, como diminuir a latência, ou seja, responder mais rápido - apesar de ser uma diferença pequena. Só que ele consome do S3 Express One Zone, que é um serviço bem mais caro. Por isso, só use o diretório se você realmente precisar.

Para o nome do bucket, podemos começar com o nome da nossa aplicação. A nossa aplicação é uma API cujo nome é coleção de fotos. Então, vamos dar esse nome do bucket: colecaodefotos.

Atenção: o nome bucket não pode ter nenhum tipo de acentuação!

Como estamos numa conta compartilhada com várias pessoas, pois é uma conta de empresa, também é comum colocar quem gere esse bucket. Nesse caso, ficará colecaodefotos-leo.

Logo abaixo, chegamos na seção de "propriedade de objeto". Vamos manter o padrão, que é "ACLs desabilitadas". Isso significa que todos os arquivos que estão no bucket são da nossa conta. Só a nossa conta pode colocar e tirar arquivos. No nosso caso, será através da API, mas tudo será nossa propriedade.

Em "configuração de bloqueio do acesso público deste bucket", podemos manter a opção "bloquear todo o acesso público". Não precisamos do acesso público no momento, já que a API é para a nossa empresa.

Também podemos deixar o versionamento desativado. Para que serve o versionamento? Suponha que você queira subir uma nova versão de uma imagem, ou seja, uma mesma imagem que já foi enviada, mas algumas diferenças. Podemos subi-la e o bucket vai guardar as duas versões. Isso é interessante em alguns casos, mas geralmente podemos deixar desativado.

Além disso, não precisamos adicionar nenhuma tag, isto é, não precisamos de nenhum comentário dentro do nosso bucket.

Na parte de "criptografia padrão", vamos deixar a cargo da AWS. Não precisamos mexer nas opções já marcadas, que selecionam uma criptografia ao lado do servidor com chaves gerenciadas do Amazon S3 e ativam a chave do bucket.

No final da página, podemos clicar em "Criar bucket". Nesse momento vai aparecer uma mensagem de sucesso:

Bucket criado com êxito "colecaodefotos-leo"

Nosso bucket vai estar listado entre os buckets de uso geral. Ao clicar em seu nome, podemos acessar os objetos dentro dele. No momento, ele está vazio, como esperado.

Especificando permissões no IAM

Podemos agora começar a criar os recursos. Então, vamos criar a API? Ainda não. Precisamos passar primeiro pela parte de permissionamento, já que estamos em um ambiente de cloud (nuvem).

É através das permissões que os serviços podem se comunicar.

É preciso criar as permissões, porque senão a API não vai conseguir acessar os arquivos do S3.

Na barra de pesquisa, na parte superior da tela, vamos digitar "IAM", que é o Identity and Access Management (Gerenciamento de acesso e identidade).

No painel do IAM, vamos ao menu da esquerda para selecionar a opção "Gerenciamento de acesso > Políticas". No lado direito, vamos clicar no botão laranja "Criar política".

Nesse momento, vamos ter que começar a especificar as permissões. Primeiramente, é preciso selecionar um serviço. Qual serviço a nossa API vai acessar? Ela vai acessar o serviço do S3.

Quais ações que ela pode fazer? No primeiro momento, vamos querer ler. Mas depois também vamos querer apagar, listar e muito mais. Por isso, em "ações permitidas", vamos marcar "todas as ações do S3". Assim, todas as ações do S3 estarão disponíveis para a nossa API.

Em "Recursos", podemos especificar um pouco melhor o que essa API vai poder acessar. No nosso caso, vamos ter que acessar um bucket. Na parte de bucket, vamos clicar em "adicionar ARNs" para restringir o acesso só para o bucket que queremos.

A API pode acessar o S3 inteiro? Não, ela tem que acessar um único local, que é o bucket da coleção de fotos. E o que precisamos para especificar? Podemos colocar o nome do bucket ou o ARN (nome do recurso da Amazon).

A melhor opção é sempre especificar o ARN, pois é um número único e exclusivo para cada recurso que criamos. Nunca existirão dois ARNs iguais.

Para pegar o ARN do nosso bucket, vamos voltar no S3 em outra aba. Dentro do bucket colecaodefotos-leo, vamos abrir a opção de "propriedades". Em "visão geral do bucket", do lado direito, já temos o nome de recurso da Amazon (ARN).

Podemos copiar o ARN e colá-lo no campo "ARN do recurso" no IAM. Com isso, já aparece o nome do bucket automaticamente. Na parte inferior direita, pressionamos "Adicionar ARNs".

Na parte de permissões, podemos rolar até o final e clicar em "Próximo" para ir à parte de "revisar e criar".

Em "Detalhes da política", precisamos colocar um nome nessa política. Para manter uma organização, vamos começar com o nome da nossa aplicação, depois o que essa política dá acesso e, por fim, informar que é uma política.

Desse modo, teremos o nome colecaodefotos-S3-policy. Assim saberemos que é uma política que dá acesso ao S3.

Para descrição, vamos copiar e colar o nome. Apesar de ser opcional, é sempre bom preencher com algo.

Na próxima seção, a AWS nos dá um resumo das permissões definidas nesta política. Na parte inferior direita, clicamos em "criar política".

Política colecaodefotos-S3-policy criada.

Criando funções

Só que os serviços não usam políticas diretamente, eles usam funções. No menu do IAM, do lado esquerdo, vamos entrar em "Funções". Na parte superior direita, apertamos o botão "Criar perfil".

A AWS tem inconsistências na tradução, às vezes chamam de funções em um lugar e perfil no outro, mas ambos significam role.

Na primeira etapa para criar um perfil, é preciso selecionar um tipo de entidade confiável. Vamos manter o "serviço da AWS".

Logo abaixo, devemos escolher um serviço ou caso de uso. Quem vai usar nossa política? No nosso caso, a API, pois ela é quem vai acessar o S3. Por isso, vamos buscar por "API Gateway". Após selecioná-lo, clicamos em "Próximo".

Não precisamos modificar nada na etapa de adicionar permissões. Vamos fazer isso mais tarde. Basta clicar em "Próximo".

Na última etapa, vamos definir o nome da função. De novo, vamos começar com o nome da nossa aplicação, coleção de fotos. Quem que vai usar essa função? O API Gateway. E ela terá acesso ao quê? Ela terá acesso ao S3. Então, será chamada colecaodefotos-APIgateway-S3.

Vamos alterar a descrição dela também, colocando a descrição igual ao nome. Podemos ir até o final da página e clicar em "Criar perfil".

Perfil colecaodefotos-APIgateway-S3 criado.

Já vamos aproveitar a notificação verde na parte superior da tela e clicar em "Visualizar função".

Na área de permissões dessa função, vamos clicar em "Adicionar permissões > anexar políticas". Em "outras políticas de permissões", buscamos pela política que acabamos de criar com o nome da nossa aplicação.

Colocar o nome da aplicação facilitar encontrar o que buscamos. Temos 900 políticas disponíveis, mas só uma com o nome da nossa aplicação. Selecionamos a colecaodefotos-S3-policy e clicamos em "Adicionar permissão" na parte inferior direita. Nosso permissionamento está feito.

Êxito ao anexar a política ao perfil.

A seguir, vamos começar a mexer no API Gateway.

Sobre o curso Amazon API Gateway: integrando e protegendo serviços

O curso Amazon API Gateway: integrando e protegendo serviços possui 125 minutos de vídeos, em um total de 50 atividades. Gostou? Conheça nossos outros cursos de AWS em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Primeira API
• API para upload
• Outros serviços
• API do app
• Protegendo a API