Dicas e truques do Kubernetes: acesso aos sites de desenvolvimento

Continuamos nossa série de artigos de instruções sobre como facilitar a vida da manutenção e dos desenvolvedores em seu trabalho diário com o Kubernetes. Todos eles são coletados de nossa experiência na solução de problemas de clientes e aprimorados ao longo do tempo, mas ainda não afirmam ser ideais - considere-os mais como idéias e espaços em branco, sugira suas soluções e melhorias nos comentários.


Desta vez, dois tópicos serão considerados, condicionalmente relacionados a um tópico: acesso do usuário ao ambiente de desenvolvimento.

1. Como fechamos circuitos dev de usuários desnecessários?

Muitas vezes enfrentamos a tarefa de fechar todo o circuito dev (dezenas / centenas de aplicativos) por trás da autenticação básica ou da lista de permissões, para que os bots de pesquisa ou apenas pessoas de terceiros não possam chegar lá.

Geralmente, para limitar o acesso, cada ingresso e aplicativo precisa criar segredos de autenticação básica separados . Gerenciá-los é muito problemático ao digitar com uma dúzia de aplicativos. Portanto, organizamos o controle de acesso centralizado.

Para fazer isso, o nginx foi criado com uma configuração desse tipo:

location / { satisfy any; auth_basic "Authentication or whitelist!"; auth_basic_user_file /etc/nginx/htpasswd/htpasswd; allow 10.0.0.0/8; allow 175.28.12.2/32; deny all; try_files FAKE_NON_EXISTENT @return200; } location @return200 { return 200 Ok; } 

Além disso, nos Ingresss do aplicativo, simplesmente adicionamos a anotação:

ingress.kubernetes.io/auth-url: "http://dev-auth.dev-auth-infra.svc.cluster.local"

Portanto, ao acessar o aplicativo, a solicitação vai para o dev-auth , que verifica se a autenticação básica correta foi inserida ou se o cliente entra na lista de permissões. Se uma das condições for atendida, a solicitação é confirmada e encaminhada para o aplicativo.



No caso de usar esse serviço, um repositório é suficiente, no qual uma lista de todos os acessos é armazenada e por meio do qual podemos configurar convenientemente nosso “centro de autorização único”. Sua distribuição para novas aplicações é realizada pela adição elementar de anotações.

2. Como fornecemos acesso a aplicativos dentro do Kubernetes em um ambiente de desenvolvimento?

... seja Redis, RabbitMQ, PostgreSQL ou desenvolvedor PHP favorito do Xdebug.

Muitas vezes, ao traduzir aplicativos para o Kubernetes, para garantir melhor segurança, precisamos bloquear o acesso externo e completamente. E então os desenvolvedores que estão acostumados a "acessar seu IDE" no banco de dados ou no Xdebug enfrentam sérias dificuldades.

Para resolver esse problema, usamos uma VPN diretamente no cluster Kubernetes. O esquema geral parece que, ao conectar-se a um servidor VPN em execução no K8s, no arquivo de configuração do OpenVPN, enviamos o endereço do servidor DNS, que também vive no K8s. O OpenVPN configura a VPN de tal maneira que, quando solicita um recurso dentro do Kubernetes, ele primeiro acessa o servidor DNS do Kubernetes - por exemplo, atrás do endereço do serviço redis.production.svc.cluster.local . O DNS no Kubernetes resolve para 10.244.1.15 e as solicitações para esse endereço IP passam pelo OpenVPN diretamente para o cluster do Kubernetes.

Durante a operação desta solução, conseguimos expandi-la repetidamente. Em particular:

1. Como não encontramos um painel de administração simples e adequado (para o nosso caso) para contabilizar o acesso à VPN , tivemos que criar nossa própria interface simples - o gráfico oficial fornece apenas a opção de iniciar comandos do console para emitir certificados.
   
   O painel de administração resultante (veja também no Docker Hub ) parece muito ascético:
   
   
   Você pode criar novos usuários ou revogar certificados antigos:
   
   
   Você também pode ver a configuração para este cliente:
   
   
2. Adicionamos autorização na VPN com base nos usuários do GitLab , onde a senha é verificada e se o usuário está ativo no GitLab. Isso ocorre nos casos em que o cliente deseja gerenciar usuários que podem se conectar à VPN de desenvolvimento apenas com base no GitLab e sem o uso de administradores adicionais - em certo sentido, ocorre "SSO para os pobres". Como base, eles adotaram o gráfico já mencionado.
   
   Para fazer isso, escrevemos um script Python que, ao conectar um usuário ao OpenVPN, usando o nome de usuário e a senha, compara o hash no banco de dados GitLab e verifica seu status (se está ativo).
   
   
   
   Aqui está o próprio script:
   
   

    #!/usr/bin/env python3 # pip3 install psycopg2-binary bcrypt import bcrypt import sys import os import psycopg2 import yaml with open("/etc/openvpn/setup/config.yaml", 'r') as ymlfile: cfg = yaml.load(ymlfile) def get_user_info(username=''): try: connect_str = "dbname=%s user=%s host=%s password=%s" % (cfg['db'], cfg['user'], cfg['host'], cfg['pass']) # use our connection values to establish a connection conn = psycopg2.connect(connect_str) # create a psycopg2 cursor that can execute queries cursor = conn.cursor() # create a new table with a single column called "name" cursor.execute("""SELECT encrypted_password,state FROM users WHERE username='%s';""" % username) # run a SELECT statement - no data in there, but we can try it rows = cursor.fetchall() print(rows) return(rows[0]) except Exception as e: print("Uh oh, can't connect. Invalid dbname, user or password?") print(e) def check_user_auth(): username = os.environ['username'] password = bytes(os.environ['password'], 'utf-8') # hashed = bcrypt.hashpw(password, bcrypt.gensalt()) user_info = get_user_info(username=username) user_encrypted_password = bytes(user_info[0], 'utf-8') user_state = True if user_info[1] == 'active' else False if bcrypt.checkpw(password, user_encrypted_password) and user_state: print("It matches!") sys.exit(0) else: print("It does not match :(") sys.exit(1) def main(): check_user_auth() if __name__ == '__main__': main() 

   
   E na configuração do OpenVPN, basta especificar o seguinte:
   
   auth-user-pass-verify /etc/openvpn/auth-user.py via-env
script-security 3
client-cert-not-required
   
   Assim, se um funcionário deixasse o cliente, ele simplesmente o desativaria no GitLab, após o qual ele não conseguiria se conectar à VPN.

Em vez de uma conclusão

Continuando uma série de artigos com receitas práticas do Flant para a operação do Kubernetes, abordarei tópicos como destacar nós individuais para tarefas específicas (por que e como?) E configurar serviços como php-fpm / gunicorn executando em contêineres para cargas pesadas. Assine o nosso blog para não perder atualizações!

PS

Outro do ciclo de dicas e truques do K8s:

• " Páginas de erro personalizadas no NGINX Ingress ";
• “ Transferência de recursos trabalhando em um cluster para gerenciamento do Helm 2 ”;
• “ Sobre a alocação de nós e a carga na aplicação web ”;
• " Acelerando a inicialização de grandes bancos de dados. "

Leia também em nosso blog:

• “ 11 maneiras de (não) se tornar uma vítima do Kubernetes Hacking ”;
• “ Construa e instale aplicativos no Kubernetes usando dapp e GitLab CI ”;
• “ Monitoramento e Kubernetes ” (revisão e reportagem em vídeo) ;
• " Nossa experiência com o Kubernetes em pequenos projetos " (reportagem em vídeo, que inclui uma introdução ao dispositivo técnico do Kubernetes) .