DEV Community: Thiago Crespo

Workload Identity GKE - Service account k8s com permissões na GCP

Thiago Crespo — Tue, 27 Jun 2023 21:20:25 +0000

O Workload Identity é um recurso do GKE (Google Kubernetes Engine) que nos permite linkar uma service account do Kubernetes com uma service account da GCP, fazendo assim, com que os Pods que utilizem esta service account, possam fazer ações permitidas na service account da GCP.

Por exemplo, temos um microserviço que faz operações em um Bucket. Então podemos criar uma service account na GCP com permissões para fazer ações em buckets, criar uma service account no Kubernetes, linkar as duas através do Workload Identity e a aplicação será automaticamente autenticada como a service account da GCP que definirmos.

Habilitando Workload Identity

Antes de começarmos a utilizar, precisamos habilitar esta funcionalidade no cluster:

Depois, precisamos habilitar o GKE Metadata Server nos node pools que possuem os worker nodes que queremos alocar os pods que irão usar a funcionalidade de Workload Identity.

Criando service account's

Criamos uma service account na GCP, que terá as permissões que o nosso Pod irá utilizar. Então criamos a service account do Kubernetes que será linkada com esta criada na GCP:

kubectl create sa -n <namespace> workload-identity-test

Então rodamos comandos com gcloud no terminal, primeiro conectamos ao project na GCP que a service account que criamos está, e depois adicionamos a role de workloadIdentityUser na service da GCP para conseguirmos linkar as duas:

gcloud config set project <nome_projeto>
gcloud iam service-accounts add-iam-policy-binding \
    <email_da_service_account_GCP> \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:production-261711.svc.id.goog[<namespace>/workload-identity-test]"

Possíveis erros:

Falta de permissão: Precisa mudar o project default do gcloud para o que você está tentando mexer: gcloud config set project <id_do_project>

gcloud crashed: Rodar gcloud components update para atualizar as dependências.

Linkar service accounts

Agora para linkar as duas service accounts, adicionamos uma annotation na do Kubernetes (k edit sa -n workload-identity-test):

apiVersion: v1
kind: ServiceAccount
metadata:
  # Adiciona esta annotation
  annotations:
    iam.gke.io/gcp-service-account: <email_service_account_GCP>
  name: workload-identity-test
  namespace: <namespace>

Para pegar achar o email da service account criada na GCP, basta ir até a service account:

Hands on

Criei um código de exemplo em NodeJS que é uma API com apenas uma rota que lista os buckets quando chamada. Para isto, eu uso a SDK da Google Cloud e a autenticação é esperada através de variáveis de ambiente.

O código está no meu Github:
https://github.com/ThiagoFelippi/workload-identity-example

Para subir no kubernetes, usei o private registry do Gitlab, e os seguintes manifestos:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: workload-identity-example
  namespace: pocs
spec:
  selector:
    matchLabels:
      app: workload-identity-example
  template:
    metadata:
      labels:
        app: workload-identity-example
    spec:
      imagePullSecrets:
      - name: workload-identity-example
      containers:
      - name: workload-identity-example
        image: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
        imagePullPolicy: IfNotPresent
        envFrom:
          - configMapRef:
              name: workload-identity-example
        ports:
        - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: workload-identity-example
  namespace: pocs
spec:
  type: ClusterIP
  selector:
    app: workload-identity-example
  ports:
    - port: 80
      targetPort: 3000

Ao subir, podemos rodar um port-forward para não precisar expor a poc através de um ingress: k port-forward svc/workload-identity-example -n pocs 3001:80

Ao acessar a rota /buckets, temos o seguinte resultado:

E podemos ver os logs do container apontando que não estamos autenticados:

Agora vamos colocar a service account que criamos para gerenciar o Deployment e ver qual o resultado. Para isto, a única coisa que muda no deployment é adicionarmos o campo serviceAccoutName dentro de spec:

...
spec:
  selector:
    matchLabels:
      app: workload-identity-example
  template:
    metadata:
      labels:
        app: workload-identity-example
    spec:
      serviceAccountName: workload-identity-test
...

E ao rodar a aplicação e entrar na rota /buckets de novo, conseguimos ver os buckets sendo listados:

Conclusões

Desta forma, aumentamos a segurança das nossas aplicações, não precisando expor dados sensíveis com a aplicação. Ensinarei em outros posts como usar isto na prática, com Helm Charts, por exemplo, com Vault, ArgoCD, etc.

Caso tenha alguma dúvida, deixe um comentário ou me chame no Linkedin: https://www.linkedin.com/in/thiago-crespo-felippi/

Migração de serverless framework v1 para v2

Thiago Crespo — Mon, 08 Nov 2021 18:41:43 +0000

Recentemente em alguns projetos que participei tive alguns desafios com relação a mudança do serverless framework de v1 para v2. No projeto utilizei NodeJS com Typescript, toda infra na AWS.

Estava utilizando a versão 1.83.2 juntamente com a imagem do docker softinstigate/serverless:1.83.0

Link da imagem: Docker Hub

Queríamos utilizar a imagem: Docker Hub

Que no momento era a mais atual. Porém tivemos alguns desafios e é sobre isto que falarei hoje

Porque?

Primeiramente, porque quisemos mudar? Simplesmente porque queríamos mexer com tecnologias mais modernas, usar features novas e nos atualizarmos afim de não termos um projeto depreciado ao longo do tempo.

Queriamos estar disponíveis para testar novas features da versão v2, aumentar a versão do node, que estava a 10 e iria começar a parar de ter suporte, etc.

Como?

Para mudar tudo precisávamos atualizar nosso pipeline de CI/CD que optamos pelo bitbucket pipeline, assim como as dependências de cada microserviço, juntamente com as imagens do docker utilizadas para rodar o pipeline.

Além de mudar a versão do serverless framework queríamos atualizar nossos plugins, afim de usar a última versão LTS de todas as dependências.

Então primeiramente atualizamos todos os pacotes relacionados ao serverless no package.json. Sejam estes os pacotes do serverless normal, plugins ou libs adicionais para rodar o serverless-offline

Atualizamos tudo, instalamos novamente as deps e mudamos os scripts do package.json para ficarem compatíveis com a nova versão (precisamos adicionar coisas de package para funcionar com o artifacts do serverless v2)

Nosso scripts de rodar local tinha algumas configs a mais para outros fins, mas poderia ser algo parecido com isto:

"scripts": {
    "debug:dev": "tsc && ./node_modules/serverless/bin/serverless.js dynamodb install && ./node_modules/serverless/bin/serverless.js offline start --noAuth --noTimeout --noPrependStageInUrl"
}

Neste caso utilizamos a dependência do dynamodb e o serverless-offline. Colocamos as flags:

--noAuth = Para não chamar o authorizer da lambda quando roda local

--noTimeout = Sem timeout fixo

--noPrependStageInUrl = Para não ter prefixo do stage nas urls, por exemplo: /dev/

Aleḿ disto a versão do node no serverless para a mais recente suportada pelo framework. E também a versão da imagem no pipeline, que optamos pelo que integra com o bitbucket.

Além disto, pesquisamos e vimos que seria bom adicionar isto no serverless.yml acima da declaração do plugins

frameworkVersion: ^2.64.1
useDotenv: true
variablesResolutionMode: 20210326

Também vimos que graças a esta atualização poderíamos remover os ~true ou ~split das enviroments chamadas lá no s3. Dado que agora ele resolve sozinho

DISCLAIMER:

Com a atualização do serverless de v1 para v2, algumas variáveis de ambiente como a LAMBDA_TASK_ROOT, tem alguns comportamentos um pouco diferentes, alguns erros que venham a acontecer podem ser graças a isto.

Depois disto tudo, rodamos nosso projeto e finalmente conseguimos ver ele funcionando no postman, isto foi muito legal, sentimos que deu tudo certo, então subimos o PR e na hora de fazer o deploy em HLG ele rolou com sucesso. Porém fomos revisar tudo e vimos que o nosso swagger tinha parado de funcionar.

A documentação no swagger foi um desafio

Para o swagger utilizávamos a biblioteca: serverless-aws-documentation

Quando fizemos o deploy pela primeira vez, nada se alterou no swagger, então apagamos o mesmo do nosso s3, e rodamos o pipeline novamente, mas não funcionou.

Então depois de muita pesquisa, descobrimos um fork desta mesma lib que é compatível com o serverless v2 :
@kakkuk/serverless-aws-apigateway-documentation

A ideia é que conseguissemos mudar a versão mexendo o mínimo possível no código, visto que temos muitos projetos é difícil migrar em todo e ficar fazendo várias coisas pra funcionar. Esta lib é 100% compatível com a que utilizávamos, assim a única coisa que tivemos que fazer pra resolver este desafio foi:

Mudar a dependência no package.json e mudar o plugin do serverless.yml do antigo para este, conforme está na descrição da dependência

Mudando isto e um pouco na parte do deploy do swagger no nosso s3 (deu problema com o staging, mas mudando um pouco resolvemos) conseguimos resolver o problema e deployar o projeto com sucesso

Mais um problema

No primeiro projeto que fizemos estávamos mexendo com Jenkins, e deu certo de primeira. Fomos replicar para os que mexiam com o bitbucket pipeline e ele começou a dar alguns erros que não estava achando as credenciais da AWS para resolver as variáveis do parameter store declaradas no serverless.yml

Investigamos e vimos que tinhamos adicionado um job a mais fora do step de deploy e isto fazia com que o bitbucket não conseguisse resolver a variável de ambiente, dado que ele só exporta as variáveis aonde tem o deployment igual ao setado nas variáveis de ambiente do repositório

Para ficar mais claro, o bitbucket pipeline tinha um step de deploy assim:

- step: &DeployHomolog
    deployment: staging
    image: softinstigate/serverless:2.43.1
    name: 'Deploy to Homolog'
    script:
      - 'DEBIAN_FRONTEND=noninteractive apt-get install -y jq'
      - 'npm run deploy:hlg'
      - 'npm run publish:reports'

E queríamos adicionar um script que usava as credencias setadas na variáveis de ambiente do projeto no ambiente de staging, porém adicionamos em outro step, porém ele não reconhecia as credenciais porque o step que tem o ambiente de staging é este, podemos ver isto pela tag deployment. Ai bastou adicionar o script neste step que funcionou

Dúvidas

De primeira pode não ser algo tão simples de resolver esta migração, mas com pesquisa e estudo vai ficando mais fácil, se alguma coisa não ficou clara e quiserem que eu esclareça podem me chamar no Linkedin e esclarecer:

Thiago Crespo Felippi - FullstackDeveloper - NTConsult | LinkedIn