Então beleza pessoal, para a gente começar aqui para falar um pouco mais sobre as pipelines de continuous deployment, a primeira coisa que a gente precisa ter em mente é que a gente precisa viabilizar um mecanismo de integração entre o Cloud Provider e o GitHub Actions, seja ele qualquer Cloud Provider e o GitHub Actions, seja ele qualquer Cloud Provider. Geralmente a gente faz essa integração utilizando o IDC, que tem como base o OpenID Connect, é uma das formas mais seguras que a gente tem atualmente para a integração entre plataformas, e vai em uma linha um pouco parecida com a que a gente já fez, plataformas e vai numa linha um pouco parecida do que a gente já fez, integrando ali com container registry e também com sonar cloud. A gente vai utilizar a AWS como exemplo, então eu já estou logado em uma conta pessoal, minha aqui, tá bom? Eu tenho permissões de administrador para a gente conseguir não ter nenhum tipo de problema na nossa demonstração. Então a primeira coisa que eu vou fazer aqui é abrir a tela do IAM, onde a gente faz todo o controle aqui de identidades né a gente tem aqui a identity providers e a gente vem aqui para adicionar uma identity provider beleza a gente consegue fazer essa integração via samuel né então aqui seria utilizando por exemplo um majorad né tipo, tipo algum Active Directory da vida, ou via OpenID Connect, e aí ele pede aqui para a gente qual que é o provider URL que a gente vai passar. Vamos acessar a documentação aqui do GitHub, escrever aqui git hub actions integration with aws beleza vamos ver o que a gente encontra aqui né a gente tem alguns pré-requisitos explica um pouquinho aqui sobre a questão do open-ed connect e a gente tem essa parte aqui que ele fala justamente para gente utilizar essa URL aqui na configuração dessa integração então vamos copiar e colar e o público-alvo a gente vai passar aqui sts-amazonaws.com Beleza, vamos criar aqui nosso provedor de identidade. Já está criado. Legal. Bom, a gente já tem o provedor de identidade configurado aqui. Mas, para a gente conseguir fazer com que qualquer repositório consiga se conectar na AWS, buscar, bater no STS da AWS, capturar o Access ID e o Secret Key, pra gente conseguir fazer a autenticação e rodar qualquer tipo de deployment, a gente vai precisar de uma role, né? Então, o segundo passo que a gente tem aqui é fazer a criação de uma role. Essa role, a gente vai escolher aqui um custom trust policy. Legal, a gente vai utilizar aqui o web identity, né? Aqui em web identity, a gente vai ter alguns que já vêm por padrão e mais o que a gente configurou agora. Então, essa linha, ela não tinha, né? Esse item. Em audience, a gente vai colocar o STS. E aí, ele pede algumas outras informações para a gente aqui. Então, uma das coisas que ele está pedindo é pra gente passar aqui o organization repository e branch o que a gente vai fazer aqui tá pessoal é a gente não tem nenhum repository nenhuma organization provisionada. Vamos criar uma organization então. A gente vai criar uma organization aqui utilizando os acessos free. O nome dessa organization vai ser vai ser fullcyclecd por exemplo e o email eu vou colocar o meu e-mail aqui pessoal a gente vai utilizar aqui my personal account vamos passar aqui pelo capture next vamos passar aqui pelo captcha next pergunta se eu quero procurar por algum username e-mail não quero legal tem algumas configurações que a gente consegue fazer aqui tipo invite para algumas pessoas tipo fazer um auto assinment de issues enfim tem uma série de configurações que a gente consegue fazer por hora a gente não vai mexer com nada só vai pegar esse nomezinho aqui a gente só vai pegar esse nomezinho aqui a gente já consegue passar aqui no nosso GitHub Organization e aqui em repository, o que seria o ideal? vamos pensar assim partindo do pressuposto de que a gente tem que ter o menor privilégio possível para qualquer coisa que a gente tem que ter o menor privilégio possível para qualquer coisa que a gente faça, a gente deveria passar, tipo, ter roles que sejam específicas por repositório. Então, se você tiver mil repositórios, você vai ter mil roles, né, cada uma dessas roles com seu devido contexto. No nosso caso, para a gente conseguir fazer isso, a gente vai precisar criar um repositório. Então, vamos criar um repositório aqui. O nome desse repositório vai ser, vou chamar aqui de Foscyco Infra. Beleza? Vai ter aqui a publicidade também com o público vou adicionar um readme e vou criar esse repositório para depois a gente poder clonar ele e aí eu já vou aproveitar e vou pegar esse repositório e vou configurar aqui também legal branch. Branch não é necessário, né? Tipo, uma vez que a gente já consegue ter ali, tipo, fechado por repositório, a gente tem uma role específica por repo, a gente consegue manipular ali diferentes branches, mas dá pra gente fazer também, né? Inclusive a gente consegue manipular branch, consegue manipular a environment tem uma série de subjects que a gente consegue passar aqui nesse tipo de contexto pra gente conseguir ter mais e mais mecanismos de proteção no nosso caso aqui a gente vai deixar dessa forma mesmo e aí ele pergunta quais são as polícias que a gente quer atachar para essa role né o ideal é que pensando aqui de forma corporativa a gente tivesse uma uma policy customizada né uma custom policy e essa custom policy ela teria tanto algumas policies gerenciadas que poderia incluir algumas dessas daqui com mais restrições e mais alguns outros acessos ali que façam sentido para aquele contexto que a gente estiver configurando. No nosso caso aqui para fins de teste, a gente vai deixar essa de administrador, que é uma policy que tem acesso total aqui na conta, mas de novo, para fins de laboratório. A gente vai dar um next. o nome da nossa role vai ser basicamente o nome do nosso repositório então vai ser fullcycle-infra a gente não vai adicionar nenhuma descrição e se a gente olhar aqui o trust dessa policy, dessa role, olha só como ele montou para a gente aqui, né? Ele colocou aqui, tipo, que a gente vai fazer uma sum role with web identity, batendo naquele identity provider que a gente configurou, né? E aí a gente também passa algumas conditions, né? Desde que a gente esteja utilizando o STS e que o nosso repositório seja da nossa organization fullcycle-cd e que o repositório tenha esse nome. Então, qualquer outro repositório que tente fazer uma sumi role utilizando nosso identity provider não vai conseguir entrar nesse contexto e vai acabar tomando aí um 401, 403 para conseguir fazer a geração dessas credenciais, tá bom? Vamos dar aqui um cliente role. Beleza. Agora a gente tem a role aqui full cycle infra com a nossa policy atachada com permissão total e aqui tipo o nosso trust configurado da forma adequada também agora a gente já consegue fazer as configração aqui com o nosso cloud provider bom eu vou clonar esse repositório então vamos clonar esse cara vou abrir ele aqui no Visual Studio Code beleza vamos lá começar a trabalhar nesse cara aqui agora