O blog da AWS

Protegendo o acesso ao Kubecost com o Amazon Cognito

Por Elamaran Shanmugam, Jayaprakash Alawala, Ramesh Kumar Venkatraman, e Re Alvarez-Parmar, traduzido por Jean Philip de Rogatis

 

Introdução

O Kubecost fornece visibilidade e insights de custos em tempo real para equipes que usam o Kubernetes. Ele tem um painel intuitivo para ajudar você a entender e analisar os custos de execução de suas cargas de trabalho em um cluster Kubernetes. O Kubecost é baseado no OpenCost, que foi recentemente aceito como um projeto Sandbox da Cloud Native Computing Foundation (CNCF), e é ativamente apoiado pela AWS.

Pacote otimizado do Kubecost para Amazon EKS

No início do ano passado, o Amazon Elastic Kubernetes Service (Amazon EKS) anunciou a disponibilidade de um pacote de Kubecost otimizado para Amazon EKS para visibilidade dos custos do cluster. O pacote está disponível gratuitamente para os clientes e inclui suporte para solução de problemas do Kubecost. Os administradores da plataforma Kubernetes e líderes financeiros podem usar o Kubecost para visualizar um detalhamento de suas cobranças do Amazon EKS, alocar custos e estornar unidades organizacionais (por exemplo, equipes de aplicativos). O Kubecost fornece às equipes internas e às unidades de negócios dados de custos transparentes e precisos com base na fatura da AWS. Os clientes também podem receber sugestões personalizadas para otimização de custos, adaptadas ao ambiente de infraestrutura e aos padrões de uso.

Usando o painel intuitivo do Kubecost, os clientes podem monitorar, analisar e alocar os custos do cluster. Quando os clientes implantam o Kubecost em um cluster, o painel é protegido pela autenticação básica do NGINX, o que não é recomendado em ambientes de produção. Esta publicação mostra como tornar o painel acessível a públicos externos, como líderes financeiros, e acesso seguro usando o Amazon Cognito.

Visão geral da solução

Tornamos o painel do Kubecost acessível fora do cluster expondo-o usando uma entrada, que usa o Application Load Balancer (ALB). Integrando o Amazon Cognito com o ALB, a solução adiciona suporte para autenticar e autorizar usuários no painel do Kubecost. Para saber mais sobre como o ALB e o Cognito se integram, consulte Como usar o Application Load Balancer e o Amazon Cognito para autenticar usuários para seus aplicativos web do Kubernetes.

Nesta postagem, usamos o padrão seguro ingress-auth-cognito EKS Blueprints para configurar:

Os clientes podem usar esse padrão para gerenciar vários clusters em ambientes com o GitOps. Consulte implantação contínua e entrega de GitOps com Amazon EKS Blueprints e ArgoCD para saber mais sobre a entrega orientada por GitOps usando padrões EKS Blueprints.

O padrão ingress-auth-cognito seguro Cloud Development Kit (CDK) inclui uma configuração de cluster Amazon EKS, configuração de capacidade computacional e complementos exigidos pelo Kubecost.

Architecture Showing how to Secure Ingress with Cognito for Kubecost application.

Pré-requisitos

Você precisa do seguinte para concluir as etapas desta postagem:

Vamos começar definindo algumas variáveis de ambiente:

ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
export AWS_REGION=${AWS_REGION:=us-west-2}

Clone o repositório cdk-eks-blueprints-patterns e instale pacotes de dependência. Esse repositório contém o código CDK v2 escrito em TypeScript.

git clone https://github.com/aws-samples/cdk-eks-blueprints-patterns.git
cd cdk-eks-blueprints-patterns
npm install
make build

O padrão ingress-auth-cognito seguro  EKS Blueprints está em lib/secure-ingress-auth-cognito/index.ts. Nesse arquivo, você pode encontrar a definição do blueprint com todas as configurações acima usando o método blueprints.eksBlueprint.builder ().

CDK do Bootstrap

A primeira etapa para qualquer implantação de CDK é inicializar o ambiente. O bootstrapping é o processo de provisionamento de recursos para o AWS CDK antes que você possa implantar aplicativos do AWS CDK em um ambiente da AWS (um ambiente da AWS é uma combinação de uma conta e região da AWS). Se você já usa o CDK em uma região, não precisa repetir o processo de inicialização.

Execute os comandos abaixo para inicializar o ambiente da AWS em sua região:

cdk bootstrap aws://$ACCOUNT_ID/$AWS_REGION

Implante o Kubecost com acesso seguro

Nesta solução, permitiremos o acesso ao painel do Kubecost com base nos endereços de e-mail do usuário. Você pode controlar o acesso ao painel permitindo a listagem de um domínio inteiro ou endereços de e-mail individuais.

É necessário que os usuários se inscrevam antes de poderem acessar o painel do Kubecost. O gatilho Lambda de pré-inscrição só permite inscrições quando o domínio de e-mail do usuário corresponde aos domínios listados como permitidos. Quando os usuários se cadastram, o Amazon Cognito envia um código de verificação para seu endereço de e-mail. Os usuários precisam verificar o acesso (usando o código válido único) ao e-mail antes de acessarem o painel.

Primeiro, criaremos um parâmetro do AWS Systems Manager (SSM) para armazenar o valor do domínio de e-mail que os usuários usam para se inscrever. Em seguida, criaremos uma variável de ambiente para armazenar o nome de domínio que hospeda o painel do Kubecost. O domínio de e-mail e o domínio usados para hospedar o painel do Kubecost podem ser iguais ou diferentes. Por exemplo, você pode escolher hospedar o painel em kubecost.myorg.mycompany.com e usar email@mycompany.org para acessar o painel.

Crie os parâmetros abaixo com endereços de e-mail e domínios permitidos no repositório de parâmetros do AWS Systems Manager:

export SSM_PARAMETER_KEY="/secure-ingress-auth-cognito/ALLOWED_DOMAINS"
export SSM_PARAMETER_VALUE="emaildomain1.com,emaildomain2.com"

aws ssm put-parameter \
  --name "$SSM_PARAMETER_KEY" \
  --value "$SSM_PARAMETER_VALUE" \
  --type "String" \
  --region $AWS_REGION

Se quiser limitar o acesso ao painel por meio de endereços de e-mail, você também pode criar um parâmetro para armazenar endereços de e-mail permitidos e adicionar uma lógica ao gatilho Lambda de pré-autenticação, conforme mostrado aqui.

Em seguida, crie um segredo no AWS Secrets Manager que você usará para acessar o ArgoCD. O segredo argo-admin-password deve ser definido como texto simples (não chave/valor):

aws secretsmanager create-secret --name argo-admin-secret \
    --description "Admin Password for ArgoCD" \
    --secret-string "password123$" \
    --region $AWS_REGION

O código CDK espera os nomes de domínio e subdomínio permitidos no arquivo de contexto do CDK (cdk.json).

Crie duas variáveis de ambiente. A variável PARENT_HOSTED_ZONE contém o nome da sua zona pública hospedada do Route 53. O DEV_SUBZONE_NAME será o endereço do seu painel do Kubecost.

Gere o arquivo cdk.json:

PARENT_HOSTED_ZONE=mycompany.a2z.com
DEV_SUBZONE_NAME=kubecost.mycompany.a2z.com
cat << EOF > cdk.json
{
    "app": "npx ts-node dist/lib/common/default-main.js",
    "context": {
        "parent.hostedzone.name": "${PARENT_HOSTED_ZONE}",
        "dev.subzone.name": "${DEV_SUBZONE_NAME}"
      }
}
EOF

Execute o comando abaixo na raiz desse repositório para implantar a solução:

make pattern secure-ingress-cognito deploy secure-ingress-blueprint

Esse comando implantará o seguinte:

Quando a implantação estiver concluída, você verá a saída semelhante à mostrada abaixo em seu terminal:

Outputs:
secure-ingress-blueprint.secureingressblueprintClusterNameD6A1BE5C = secure-ingress-blueprint
secure-ingress-blueprint.secureingressblueprintConfigCommandD0275968 =  aws eks update-kubeconfig —name secure-ingress-blueprint —region us-west-2 —role-arn arn:aws:iam::<ACCOUNT ID>:role/secure-ingress-blueprint-secureingressblueprintMas-XXXXXXXXXX
secure-ingress-blueprint.secureingressblueprintGetTokenCommand21BE2184 =  aws eks get-token —cluster-name secure-ingress-blueprint —region us-west-2 —role-arn arn:aws:iam::<ACCOUNT ID>:role/secure-ingress-blueprint-secureingressblueprintMas-XXXXXXXXXX

Stack ARN:
arn:aws:cloudformation:us-west-2:<ACCOUNT ID>:stack/secure-ingress-blueprint/XXXXXXXXXX

Para atualizar a configuração do Kubernetes para seu novo cluster, copie e execute o comando aws eks update-kubeconfig (o segundo comando na saída) em seu terminal.

export EKS_KUBECONFIG=$(aws cloudformation describe-stacks \
  --stack-name secure-ingress-blueprint \
  --query "Stacks[0].Outputs[?starts_with(OutputKey, 'secureingressblueprintConfigCommand')].OutputValue" \
  --region $AWS_REGION \
  --output text)

eval $EKS_KUBECONFIG

Valide o acesso ao seu cluster Amazon EKS usando o kubectl abaixo listando todos os namespaces:

kubectl get namespace

Você deve ver os seguintes namespaces no cluster:

NAME              STATUS   AGE
argocd            Active   30m
default           Active   39m
external-dns      Active   30m
kube-node-lease   Active   39m
kube-public       Active   39m
kube-system       Active   39m
kubecost          Active   30m

A pilha implanta recursos do Kubecost no namespace kubecost.

kubectl -n kubecost get all
NAME                                                             READY   STATUS    RESTARTS   AGE
pod/kubecost-cost-analyzer-84d5775f7b-zg8mq                      2/2     Running   0          88m
pod/kubecost-cost-analyzer-grafana-69d77ccd6d-9r8rc              2/2     Running   0          88m
pod/kubecost-cost-analyzer-kube-state-metrics-789fc978c8-ch8lb   1/1     Running   0          88m
pod/kubecost-cost-analyzer-prometheus-node-exporter-w9w75        1/1     Running   0          88m
pod/kubecost-cost-analyzer-prometheus-server-6dc99564bf-mz9nw    2/2     Running   0          88m

NAME                                                      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
service/kubecost-cost-analyzer-cost-analyzer              ClusterIP   172.20.193.130   <none>        9003/TCP,9090/TCP   88m
service/kubecost-cost-analyzer-grafana                    ClusterIP   172.20.143.32    <none>        80/TCP              88m
service/kubecost-cost-analyzer-kube-state-metrics         ClusterIP   172.20.165.147   <none>        8080/TCP            88m
service/kubecost-cost-analyzer-prometheus-node-exporter   ClusterIP   None             <none>        9100/TCP            88m
service/kubecost-cost-analyzer-prometheus-server          ClusterIP   172.20.54.102    <none>        80/TCP              88m

NAME                                                             DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/kubecost-cost-analyzer-prometheus-node-exporter   1         1         1       1            1           <none>          88m

NAME                                                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/kubecost-cost-analyzer                      1/1     1            1           88m
deployment.apps/kubecost-cost-analyzer-grafana              1/1     1            1           88m
deployment.apps/kubecost-cost-analyzer-kube-state-metrics   1/1     1            1           88m
deployment.apps/kubecost-cost-analyzer-prometheus-server    1/1     1            1           88m

Testando a autenticação

Aponte seus navegadores para a URL que você associou à chave DEV_SUBZONE_NAME do contexto do CDK para acessar o painel do Kubecost.

O valor também é armazenado como uma variável de ambiente:

echo $DEV_SUBZONE_NAME

Seu navegador será redirecionado para uma página de login da interface de usuário (UI) hospedada pelo Amazon Cognito. Como essa é a primeira vez que você acessa o aplicativo, selecione inscrever-se.

O gatilho de pré-inscrição do AWS Lambda para o pool de usuários do Amazon Cognito está configurado para permitir que os usuários se registrem somente em determinados domínios de e-mail listados como permitidos. Os domínios de e-mail listados como permissões são configurados como uma variável ambiental na função AWS Lambda. Vamos tentar inscrever um novo usuário usando um ID de e-mail, cujo domínio não faz parte da lista de permissões.

Screenshot of sign-in page

Você receberá um erro, pois o domínio não está na lista de permissões.

Screenshot of error message

Vamos nos inscrever como um novo usuário com um dos domínios de e-mail listados como permitidos. Dessa vez, você receberá uma solicitação para confirmar sua conta. Receba o código de verificação em seu e-mail e confirme sua conta.

Screenshot of account verification page

Depois de verificar o endereço de e-mail, faça login para acessar o painel do Kubecost

Depois de fazer login, o ALB o redirecionará para o painel do Kubecost:

Kubecost dashboard

Limpando

Você continua incorrendo em custos até excluir a infraestrutura que criou para esta publicação. Use os comandos abaixo para excluir os recursos criados durante esta postagem:

make pattern secure-ingress-cognito destroy secure-ingress-blueprint

Conclusão

Nesta postagem, mostramos como proteger o painel do Kubecost e, ao mesmo tempo, torná-lo acessível aos usuários sem precisar acessar o cluster do Kubernetes. Usamos um ALB para expor o painel e o acesso seguro usando o Cognito. Também criamos um registro no Route 53 para que os usuários possam acessar facilmente o painel.

Usamos o pool de usuários do Cognito para armazenar informações do usuário. Se você já tem um provedor de identidade que fornece suporte ao OpenID Connect (OIDC) ou SAML 2.0, você pode integrá-lo ao Cognito para pular a inscrição e fazer login no painel do Kubecost.

 

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Elamaran (Ela) Shanmugam é arquiteto sênior de soluções especialista em contêineres da AWS. Ela é um PME de arquitetura de contêineres, observabilidade e várias contas e ajuda os clientes a projetar e criar cargas de trabalho de contêineres escaláveis, seguras e otimizadas na AWS. Sua paixão é criar e automatizar a infraestrutura para permitir que os clientes se concentrem mais em seus negócios. Ele mora em Tampa, Flórida, e você pode contatá-lo no twitter @IamElaShan.

 

 

 

 

Jayaprakash Alawala é arquiteta sênior de soluções especialista em contêineres na AWS. Ele ajuda os clientes na modernização de aplicativos e na criação de aplicativos de grande escala usando vários serviços da AWS. Ele tem experiência na área de contêineres, microsserviços, operações de desenvolvimento, segurança, otimização de custos, incluindo EC2 Spot, treinamento técnico. Fora do trabalho, ele adora passar o tempo lendo e viajando. Você pode contatá-lo no twitter @JP_Alawala.

 

 

 

 

Ramesh Kumar Venkatraman é arquiteto de soluções na AWS e é apaixonado por contêineres e bancos de dados. Ele trabalha com clientes da AWS para projetar, implantar e gerenciar suas cargas de trabalho e arquiteturas da AWS. Em seu tempo livre, ele adora brincar com seus dois filhos e segue críquete.

 

 

 

 

Re Álvarez-Parmar é arquiteto de soluções especialista em contêineres na Amazon Web Services, Re assessora equipes de engenharia na modernização e criação de serviços distribuídos na nuvem. Antes de ingressar na AWS, ele passou mais de 15 anos como arquiteto corporativo e de software. Ele mora em Seattle. Conecte-se no LinkedIn em: linkedin.com/in/realvarez.

 

 

 

 

Tradutor

Jean Philip de Rogatis é arquiteto de soluções sênior na AWS, Trabalha na indústria de Entusiasta de novas tecnologias, construiu mais de 10 sistemas, de soluções de big data a portais de vendas, entregando um crescimento YoY de três dígitos e liderando uma equipe de 50+ pessoas. Ajuda empresas a transformar seus negócios, adotando tecnologias baseadas em nuvem para encantar seus clientes, parceiros e funcionários.

Me siga no LinkedIn: https://www.linkedin.com/in/jrogatis/