One place for hosting & domains

      recomendados

      Passos recomendados para proteger o HTTP Apache no FreeBSD 12.0


      O autor selecionou o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      Embora a instalação padrão de um servidor HTTP Apache já seja segura para usar, sua configuração pode ser melhorada substancialmente com algumas modificações. É possível complementar os mecanismos de segurança atuais como, por exemplo, definindo proteções em torno de cookies e cabeçalhos, de modo que as conexões não possam ser alteradas no nível cliente do usuário. Ao fazer isso, é possível reduzir drasticamente as possibilidades de vários métodos de ataque, como ataques de Cross-Site Scripting (também conhecidos por XSS). Também é possível evitar outros tipos de ataques, como a solicitação intersite forjada (XSRF), ou sequestro de sessão, bem como ataques de negação de serviço.

      Neste tutorial, você implementará alguns passos recomendados para reduzir o nível de exposição das informações em seu servidor. Você verificará as listas de diretórios e desativará a indexação para verificar o acesso aos recursos. Você também vai alterar o valor padrão da diretiva timeout, para ajudar a mitigar os ataques do tipo negação de serviço. Além disso, você desativará o método TRACE, de modo que as sessões não possam ser invertidas e sequestradas. Por fim, protegerá cabeçalhos e cookies.

      A maioria das definições de configuração serão aplicadas ao arquivo de configuração principal do HTTP Apache encontrado em /usr/local/etc/apache24/httpd.conf.

      Pré-requisitos

      Antes de iniciar este guia, você precisará do seguinte:

      Com os pré-requisitos instalados, você terá um sistema FreeBSD com uma pilha sobre ele, capaz de atender o conteúdo Web usando qualquer coisa escrita em PHP, tais como softwares de CMS importantes. Além disso, você criptografou conexões seguras através do Let’s Encrypt.

      Reduzindo as informações do servidor

      A faixa do sistema operacional é um método usado por computadores, servidores e dispositivos de todos os tipos para se apresentarem nas redes. Atores mal-intencionados podem usar essa informação para conseguir acesso às vulnerabilidades de sistemas relevantes. Nesta seção, você reduzirá a quantidade de informações publicadas por essa faixa.

      Conjuntos de diretivas controlam como essa informação é exibida. Para essa finalidade, a diretiva ServerTokens é importante; por padrão, ela mostra todos os detalhes sobre o sistema operacional e os módulos compilados para o cliente que está se conectando a ele.

      Você usará uma ferramenta de verificação de rede para conferir quais informações são atualmente reveladas, antes de aplicar qualquer alteração. Para instalar o nmap, execute o seguinte comando:

      Para obter o endereço IP do seu servidor, execute o seguinte comando:

      • ifconfig vtnet0 | awk '/inet / {print $2}'

      Verifique a resposta do servidor Web, usando o seguinte comando:

      • nmap -sV -p 80 your-server-ip

      Você invoca o nmap para fazer uma verificação (por conseguinte, o sinalizador -s), para exibir a versão (o sinalizador -V) na porta 80 (o sinalizador -p) de um determinado IP ou domínio.

      Você receberá informações sobre seu servidor Web, semelhantes às seguintes:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:30 CET Nmap scan report for 206.189.123.232 Host is up (0.054s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.41 ((FreeBSD) OpenSSL/1.1.1d-freebsd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Esse resultado mostra que informações como o sistema operacional, a versão HTTP Apache e o OpenSSL estão visíveis. Isso pode ser útil para que invasores consigam informações sobre o servidor e escolham as ferramentas certas para acessar, por exemplo, uma vulnerabilidade no software que está em execução no servidor.

      Você colocará a diretiva ServerTokens no arquivo de configuração principal, já que ela não vem configurada por padrão. A falta dessa configuração faz com que o HTTP Apache mostre toda a informação sobre o servidor, da maneira como está na documentação. Para limitar as informações que são reveladas sobre seu servidor e configuração, você colocará a diretiva ServerTokens dentro do arquivo de configuração principal.

      Coloque essa diretiva após a entrada ServerName, no arquivo de configuração. Execute o seguinte comando para encontrar a diretiva:

      • grep -n 'ServerName' /usr/local/etc/apache24/httpd.conf

      Você encontrará o número da linha que você poderá pesquisar com o vi:

      Output

      226 #ServerName www.example.com:80

      Execute o seguinte comando:

      • sudo vi +226 /usr/local/etc/apache24/httpd.conf

      Adicione a linha destacada a seguir:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #ServerName www.example.com:80
      ServerTokens Prod
      

      Salve e saia do arquivo com :wq e ENTER.

      Definir a diretiva ServerTokens para Prod fará com que ela exiba apenas que este é um servidor Web Apache.

      Para que isso entre em vigor, reinicie o servidor HTTP Apache:

      Para testar as alterações, execute o seguinte comando:

      • nmap -sV -p 80 your-server-ip

      Você verá um resultado semelhante ao seguinte, com informações reduzidas sobre seu servidor Web Apache:

      Output

      Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-22 00:58 CET Nmap scan report for WPressBSD (206.189.123.232) Host is up (0.056s latency). PORT STATE SERVICE VERSION 80/tcp open http Apache httpd Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

      Você viu quais informações o servidor estava anunciando antes da mudança e agora reduziu isso a um mínimo. Com isso, estará fornecendo menos pistas sobre seu servidor a um agente externo. No próximo passo, você irá gerenciar as listagens de diretórios para seu servidor Web.

      Gerenciando listagens de diretórios

      Neste passo, você irá assegurar que a listagem de diretórios esteja devidamente configurada, de modo que as partes certas do sistema fiquem publicamente disponíveis, conforme pretendido, ao passo que as demais partes fiquem protegidas.

      Nota: quando um argumento estiver declarado como estando ativo, o sinal de adição + poderá reforçar visualmente que ele está, de fato, habilitado. Quando um sinal de subtração - for usado, significa que o argumento foi negado como, por exemplo, em Options -Indexes.

      Argumentos com sinais de adição + e/ou de subtração - não podem ser misturados, pois esta é uma sintaxe considerada ruim no HTTP Apache e pode ser rejeitada na inicialização.

      Adicionar a instrução Options -Indexes definirá o conteúdo dentro do caminho de dados /usr/local/www/apache24/data para não indexar (leia listado) automaticamente se não existir um arquivo .html e para não exibir se um URL mapear esse diretório. Isso também se aplicará quando usar configurações de host virtual, como a que foi usada no tutorial com os pré-requisitos para o certificado Let’s Encrypt.

      Você definirá a diretiva Options com o argumento -Indexes e com a diretiva +FollowSymLinks, o que permitirá que links simbólicos sejam seguidos. Você usará o símbolo + para cumprir com as convenções do HTTP do Apache.

      Execute o seguinte comando para encontrar a linha a ser editada no arquivo de configuração:

      • grep -n 'Options Indexes FollowSymLinks' /usr/local/etc/apache24/httpd.conf

      Você verá um resultado similar ao seguinte:

      Output

      263 : Options Indexes FollowSymLinks

      Execute este comando para acessar diretamente a linha para edição:

      • sudo vi +263 /usr/local/etc/apache24/httpd.conf

      Agora, edite a linha de acordo com a configuração:

      /usr/local/etc/apache24/httpd.conf

      . . .
      #
      Options -Indexes +FollowSymLinks
      
      #
      . . .
      

      Salve e saia do arquivo com :wq e ENTER.

      Reinicie o HTTP Apache para implementar estas alterações:

      No seu domínio, no navegador, você verá uma mensagem de acesso proibido, também conhecida como erro 403. Isso se deve às alterações que você aplicou. Colocar -Indexes na diretiva Options desabilitou a capacidade de auto-indexação do HTTP Apache e, portanto, não haverá nenhum arquivo index.html no caminho dos dados.

      Você pode resolver isso, colocando um arquivo index.html dentro do VirtualHost que você habilitou no tutorial com os pré-requisitos para o certificado Let’s Encrypt. Você usará o bloco padrão dentro do HTTP Apache e o colocará na mesma pasta que o DocumentRoot que tiver declarado no host virtual.

      /usr/local/etc/apache24/extra/httpd-vhosts.conf

      <VirtualHost *:80>
          ServerAdmin your_email@your_domain.com
          DocumentRoot "/usr/local/www/apache24/data/your_domain.com"
          ServerName your_domain.com
          ServerAlias www.your_domain.com
          ErrorLog "/var/log/your_domain.com-error_log"
          CustomLog "/var/log/your_domain.com-access_log" common
      </VirtualHost>
      

      Use o comando a seguir para fazer isso:

      • sudo cp /usr/local/www/apache24/data/index.html /usr/local/www/apache24/data/your_domain.com/index.html

      Agora você verá uma mensagem It works! (Funciona!) ao visitar o seu domínio.

      Nesta seção, você definiu restrições na diretiva dos Indexes, de modo a não listar nem exibir automaticamente o conteúdo, exceto o que você quiser que seja listado e exibido. Agora, caso não haja um arquivo index.html dentro do caminho de dados, o HTTP Apache não criará automaticamente um índice dos conteúdos. No próximo passo, você irá além do ocultamento de informações e personalizará diferentes diretivas.

      Reduzindo o valor da diretiva de Tempo Limite

      A diretiva Timeout (tempo limite) define o limite de tempo que o HTTP Apache vai aguardar por novas entradas/saídas, antes de falhar o pedido de conexão. Esta falha pode ocorrer devido a diversas circunstâncias, como pacotes que não chegam no servidor ou dados que não estão sendo confirmados como recebidos pelo cliente.

      Por padrão, o tempo limite é definido em 60 segundos. Em ambientes onde o serviço de internet é lento, esse valor padrão pode fazer sentido. No entanto, um minuto é um tempo consideravelmente longo, especialmente se o servidor estiver cobrindo usuários alvo com um serviço de internet mais rápido. Além disso, durante o tempo em que o servidor não está fechando, a conexão pode ser explorada para a realização de ataques de negação de serviço (do inglês, DoS). Caso uma enorme quantidade dessas conexões mal-intencionadas ocorra, o servidor irá fraquejar e possivelmente ficará saturado e deixará de responder.

      Para alterar o valor, encontre as entradas de Timeout no arquivo httpd-default.conf:

      • grep -n 'Timeout' /usr/local/etc/apache24/extra/httpd-default.conf

      Você verá um resultado parecido com este:

      Output

      8 # Timeout: The number of seconds before receives and sends time out. 10 Timeout 60 26 # KeepAliveTimeout: Number of seconds to wait for the next request from the 29 KeepAliveTimeout 5 89 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

      No resultado, a linha 10 define o valor da diretiva Timeout. Para acessar diretamente essa linha, execute o seguinte comando:

      • sudo vi +10 /usr/local/etc/apache24/extra/httpd-default.conf

      Você irá alterar o valor para 30 segundos, assim como no exemplo a seguir:

      /usr/local/etc/apache24/extra/httpd-default.conf

      #
      # Timeout: The number of seconds before receives and sends time out.
      #
      Timeout 30
      

      Salve e saia do arquivo com :wq e ENTER.

      O valor da diretiva Timeout precisa equilibrar um intervalo longo o bastante, para que tais eventos permitam que uma conexão legítima e bem-sucedida ocorra, mas suficientemente curto para evitar tentativas de conexão indesejadas.

      Nota: os ataques de negação de serviço podem drenar os recursos do servidor de modo bastante eficaz. Uma contramedida complementar e bem eficaz é usar um MPM (Multi-Processing Module [Módulo de processamento múltiplo]) encadeado para conseguir o melhor desempenho da maneira como o HTTP Apache lida com conexões e processos. No tutorial sobre Como configurar o HTTP Apache com o evento MPM e PHP-FPM no FreeBSD 12.0, há passos sobre como habilitar essa capacidade.

      Para que essa alteração entre em vigor, reinicie o servidor HTTP Apache:

      Você alterou o valor padrão da diretiva Timeout para mitigar parcialmente os ataques de DoS.

      Desabilitando o método TRACE

      O HTTP (Hypertext Transport Protocol [Protocolo de Transporte de Hipertexto]) foi desenvolvido de acordo com um modelo cliente-servidor e, como tal, o protocolo tem métodos de solicitação para recuperar ou posicionar informações vindas do servidor ou enviadas para ele. O servidor precisa entender esses conjuntos de métodos e como eles interagem entre si. Neste passo, você irá configurar os métodos mínimos necessários.

      O método TRACE – antes considerado inofensivo – foi potencializado para a realizar ataques de rastreamento intersites. Esses tipos de ataques permitem que atores mal-intencionados roubem as sessões do usuário através desse método. O método foi projetado para a finalidade de depuração pelo servidor, retornando o mesmo pedido enviado originalmente pelo cliente. Como o cookie da sessão do navegador é enviado para o servidor, ele será enviado de volta novamente. No entanto, possivelmente isso poderia ser interceptado por um ator mal-intencionado que poderia, então, redirecionar a conexão de um navegador para um site controlado por ele e não para o servidor original.

      Devido à possibilidade do uso indevido do método TRACE, é recomendável usá-lo apenas para depuração e não na produção. Nesta seção, você desativará esse método.

      Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Adicione o seguinte caminho de entrada ao final do arquivo:

      /usr/local/etc/apache24/httpd.conf

      . . .
      TraceEnable off
      

      Uma prática recomendável é especificar apenas os métodos que você usará no seu servidor Web HTTP Apache. Isso ajudará a limitar possíveis pontos de entrada para atores mal-intencionados.

      O LimitExcept pode ser útil para este propósito, uma vez que ele não permite nenhum outro método senão os que estão declarados nele. Por exemplo, uma configuração pode ser estabelecida desta forma:

      /usr/local/etc/apache24/httpd.conf

      DocumentRoot "/usr/local/www/apache24/data"
      <Directory "/usr/local/www/apache24/data">
          Options -Indexes +FollowSymLinks -Includes
          AllowOverride none
           <LimitExcept GET POST HEAD>
             deny from all
          </LimitExcept>
          Require all granted
      </Directory>
      

      Como declarado dentro da diretiva LimitExcept, apenas os métodos GET, POST e HEAD foram permitidos na configuração.

      • O método GET faz parte do protocolo HTTP e é usado para recuperar dados.
      • O método POST também faz parte do protocolo HTTP e é usado para enviar dados ao servidor.
      • O método HEAD é semelhante ao GET, porém, ele não possui nenhum corpo de resposta.

      Você usará o comando a seguir e colocará o bloco LimitExcept dentro do arquivo:

      • sudo vi +272 /usr/local/etc/apache24/httpd.conf

      Para definir essa configuração, você colocará o seguinte bloco na entrada da diretiva DocumentRoot, a partir do qual o seu conteúdo será lido, mais especificamente dentro da entrada Directory:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <LimitExcept GET POST HEAD>
         deny from all
      </LimitExcept>
      . . .
      

      Para aplicar as alterações, reinicie o HTTP Apache:

      A diretiva mais recente AllowedMethods oferece funcionalidades semelhantes, embora ainda esteja com status experimental.

      Você viu o que são os métodos HTTP, seus usos e a proteção que oferecem contra atividades mal-intencionadas, que potencializam o método TRACE, além de como declarar quais métodos usar. A seguir, você trabalhará com proteções adicionais, dedicadas aos cabeçalhos e cookies HTTP.

      Protegendo cabeçalhos e cookies

      Neste passo, você irá configurar diretivas específicas para proteger as sessões que as máquinas clientes abrirão ao visitar seu servidor Web HTTP Apache. Dessa forma, seu servidor não irá carregar conteúdo indesejado, a criptografia não será reduzida e você evitará a detecção de conteúdo.

      Os cabeçalhos são componentes dos métodos de solicitação. Existem cabeçalhos para ajustar a autenticação, a comunicação entre servidor e cliente, o cache, a negociação de conteúdo etc.

      Os cookies são partes de informações enviadas pelo servidor para o navegador. Essas partes permitem que o servidor reconheça o navegador do cliente de um computador para outro. Elas também permitem que os servidores reconheçam as sessões dos usuários. Por exemplo, elas podem rastrear um carrinho de compras de um usuário conectado, informações de pagamento, histórico e assim por diante. Os cookies são usados e mantidos no navegador Web do cliente, uma vez que o HTTP é um protocolo sem estado, ou seja, assim que a conexão se fecha, o servidor não se lembra do pedido enviado por um cliente, ou outro.

      É importante proteger os cabeçalhos, bem como os cookies, pois eles proporcionam comunicação entre o cliente do navegador Web e o servidor Web.

      O módulo headers (cabeçalhos) vem ativado por padrão. Para verificar se ele está carregado, use o seguinte comando:

      • sudo apachectl -M | grep 'headers'

      Você verá o seguinte resultado:

      Output

      headers_module (shared)

      Se não ver nenhum resultado, verifique se o módulo está ativado dentro do arquivo do Apache httpd.conf:

      • grep -n 'mod_headers' /usr/local/etc/apache24/httpd.conf

      Como resultado, você verá uma linha não comentada, referindo-se ao módulo específico para os cabeçalhos:

      /usr/local/etc/apache24/httpd.conf

      . . .
      122  LoadModule headers_module libexec/apache24/mod_headers.so
      . . .
      

      Remova a hashtag no início da linha mod_headers.so, se houver, para ativar a diretiva.

      Ao utilizar as diretivas do HTTP Apache a seguir, você protegerá os cabeçalhos e cookies de atividade mal-intencionada, reduzindo o risco para clientes e servidores.

      Agora, você irá configurar a proteção do cabeçalho. Você colocará todos esses valores de cabeçalho em um bloco. Você pode escolher aplicar esses valores como desejar, mas todos são recomendados.

      Edite o arquivo httpd.conf com o comando a seguir e, em seguida, pressione G para chegar ao final do arquivo:

      • sudo vi /usr/local/etc/apache24/httpd.conf

      Posicione o seguinte bloco ao final do arquivo:

      /usr/local/etc/apache24/httpd.conf

      . . .
      <IfModule mod_headers.c>
        # Add security and privacy related headers
        Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;"
        Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always edit Set-Cookie (.*) "$1; HttpOnly; Secure"
        Header set X-Content-Type-Options "nosniff"
        Header set X-XSS-Protection "1; mode=block"
        Header set Referrer-Policy "strict-origin"
        Header set X-Frame-Options: "deny"
        SetEnv modHeadersAvailable true
      </IfModule>
      
      • Header set Strict-Transport-Security "max-age=31536000; includeSubDomains": o HTTP Strict Transport Security (HTSTS) [Segurança de Transporte Estrito HTTP] é um mecanismo para servidores e clientes Web (principalmente navegadores) para estabelecer comunicações usando apenas HTTPS. Ao implementar isso, você está evitando ataques de intermediários (do inglês, man-in-the-middle ou MITM), nos quais um terceiro, no meio da comunicação, possivelmente poderia acessar partes dos dados, bem como adulterá-las.

      • Header always edit Set-Cookie (. *) "$1; HttpOnly; Secure": os sinalizadores HttpOnly e Secure nos cabeçalhos ajudam a evitar ataques de script intersites, também conhecidos como XSS. Invasores podem usar os cookies indevidamente, passando-se por visitantes legítimos, ou seja, apresentando-se como outras pessoas (roubo ou falsificação de identidade).

      • Header set Referrer-Policy "strict-origin": o cabeçalho Referrer-Policy define quais informações são incluídas como informações de referenciador no campo do cabeçalho.

      • Header set Content-Security-Policy "default-src 'self'; upgrade-insecure-requests;": o cabeçalho Content-Security-Policy (CSP) evitará completamente o carregamento de conteúdo não especificado nos parâmetros, o que é útil para prevenir ataques de scripts intersites (XSS). Existem muitos parâmetros possíveis para configurar a política para este cabeçalho. A linha final está configurando-o para carregar conteúdo a partir do mesmo site e atualizar qualquer conteúdo com origem de HTTP.

      • Header set X-XSS-Protection "1; mode=block": este cabeçalho é compatível com navegadores mais antigos que não estão à altura dos cabeçalhos Content-Security-Policy. O cabeçalho ‘X-XSS-Protection’ fornece proteção contra os ataques de script intersites. Você não precisa definir esse cabeçalho, a menos que precise dar suporte às versões antigas de navegadores, o que é raro.

      • Header set X-Frame-Options: "deny": isso impede os ataques de clickjacking [ataques à interface do usuário]. O cabeçalho ‘X-Frame-Options’ diz a um navegador se uma página pode ser renderizada em um <frame>, <iframe>, <embed> ou <object>. Dessa forma, o conteúdo de outros sites não pode ser inserido em outros, impedindo os ataques de clickjacking. Aqui, você está negando toda renderização de quadros, para que a página Web não possa ser inserida em nenhum outro lugar, nem mesmo dentro do mesmo site. Você pode adaptar isso às suas necessidades, caso, por exemplo, precise autorizar a renderização de algumas páginas por se tratarem de anúncios ou colaborações com sites específicos.

      • Header set X-Content-Type-Options "nosniff": o cabeçalho ‘X-Content-Type-Options’ controla os tipos MIME, de modo que não sejam alterados nem seguidos. Os tipos MIME são padrões de formatos de arquivos; eles funcionam para texto, áudio, vídeo, imagem etc. Esse cabeçalho impede que atores mal-intencionados detectem tais arquivos e tentem alterar os tipos de arquivos.

      Agora, reinicie o Apache para que as alterações entrem em vigor:

      Para verificar os níveis de segurança das suas configurações, visite o site de cabeçalhos de segurança. Após seguir os passos neste tutorial, seu domínio irá obter uma nota A.

      Nota: se você fizer a verificação dos seus cabeçalhos visitando o sitehttps://securityheaders.com/ e obtiver uma nota F, isso pode significar que não há um index.html dentro do DocumentRoot do seu site – conforme instrução ao final do Passo 2. Se, ao fazer a verificação dos seus cabeçalhos, você obtiver uma nota diferente de A, ou F, verifique cada linha do Header set, procurando por eventuais erros de ortografia que possam ter levado à redução da nota.

      Neste passo, você trabalhou com até sete configurações para melhorar a segurança dos seus cabeçalhos e cookies. Esses recursos ajudarão a evitar ataques do tipo script intersites, clickjacking, entre outros.

      Conclusão

      Neste tutorial, você lidou com vários aspectos de segurança, desde a divulgação de informações, até a proteção de sessões, definindo ajustes alternativos na configuração de funcionalidades importantes.

      Para obter mais recursos para proteger o Apache, aqui estão algumas outras referências:

      Para obter outras ferramentas para proteger o HTTP Apache:



      Source link

      Passos recomendados para proteger um cluster Kubernetes da DigitalOcean


      O autor selecionou a Open Sourcing Mental Illness para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Kubernetes, a plataforma de orquestração de contêineres de código aberto, tem se tornado a solução preferida para automatização, ampliação e gerenciamento de clusters de alta disponibilidade. Como resultado de sua popularidade crescente, a segurança do Kubernetes tornou-se cada vez mais relevante.

      Considerando as partes que se movem envolvidas no Kubernetes e os vários cenários de implantação, proteger o Kubernetes pode ser por vezes complexo. Por isso, o objetivo deste artigo é fornecer uma base de segurança sólida para um cluster Kubernetes da DigitalOcean (DOKS). Note que este tutorial aborda as medidas de segurança básicas para o Kubernetes e deve ser um ponto de partida em vez de um guia exaustivo. Para obter passos adicionais, consulte a documentação oficial do Kubernetes.

      Neste guia, você fará os passos básicos para proteger seu cluster Kubernetes da DigitalOcean. Você configurará a autenticação local segura com certificados TLS/SSL, concederá permissões aos usuários locais com os controles de acesso baseados em papel (RBAC), permissões para aplicativos e implantações do Kubernetes com contas de serviço e configurará os limites de recurso com os contêineres de admissão ResourceQuota e LimitRange.

      Pré-requisitos

      Para completar este tutorial, você precisará de:

      Passo 1 — Habilitando a autenticação de usuário remoto

      Após completar os pré-requisitos, você terá um superusuário Kubernetes que se autentica por meio de um token pré-definido ao portador da DigitalOcean. No entanto, compartilhar essas credenciais não é uma boa prática de segurança, uma vez que essa conta pode causar alterações importantes e possivelmente destrutivas no seu cluster. Para mitigar essa possibilidade, configure usuários adicionais a serem autenticados a partir dos seus respectivos clientes locais.

      Nesta seção, você autenticará novos usuários para o cluster DOKS remoto de clientes locais usando certificados SSL/TLS seguros. Este será um processo de três passos: primeiro, você criará as Solicitações de assinatura de certificados (CSR) para cada usuário e, em seguida, aprovará esses certificados diretamente no cluster através do kubectl. Por fim, você construirá para cada usuário um arquivo kubeconfig com os certificados apropriados. Para obter mais informações sobre métodos de autenticação adicionais compatíveis com o Kubernetes, consulte a documentação de autenticação do Kubernetes.

      Como criar pedidos de assinatura de certificados para novos usuários

      Antes de começar, verifique a conexão de cluster DOKS a partir da máquina local configurada durante os pré-requisitos:

      Dependendo da sua configuração, o resultado será semelhante a este:

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Isso significa que você está conectado ao cluster DOKS.

      Em seguida, crie uma pasta local para os certificados do cliente. Para os fins deste guia, o ~/certs será usado para armazenar todos os certificados:

      Neste tutorial, vamos autorizar um novo usuário chamado sammy para acessar o cluster. Sinta-se à vontade para alterar isso para um usuário de sua escolha. Usando a biblioteca SSL e TLS OpenSSL, gere uma nova chave privada para seu usuário usando o seguinte comando:

      • openssl genrsa -out ~/certs/sammy.key 4096

      A flag -out criará o arquivo de saída ~/certs/sammy.key, e 4096 define a chave como 4096-bit. Para obter mais informações sobre o OpenSSL, consulte nosso guia Fundamentos do OpenSSL.

      Agora, crie um arquivo de configuração para solicitação de assinatura de certificado. Abra o arquivo a seguir com um editor de texto (para este tutorial, usaremos o nano):

      • nano ~/certs/sammy.csr.cnf

      Adicione o seguinte conteúdo ao arquivo sammy.csr.cnf para especificar no assunto o nome de usuário desejado como nome comum (CN) e o grupo como organização (O):

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      O arquivo de configuração de solicitação de assinatura de certificado contém todas as informações necessárias, identidade do usuário e os parâmetros de uso adequados para o usuário. O último argumento extendedKeyUsage=serverAuth,clientAuth permitirá que os usuários autentiquem seus clientes locais com o cluster DOKS usando o certificado assim que ele estiver assinado.

      Em seguida, crie a solicitação de assinatura de certificado sammy:

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      O -config permite que você especifique o arquivo de configuração para o CSR, e -new sinaliza que você está criando uma nova CSR para a chave especificada por -key.

      Verifique sua solicitação de assinatura de certificado executando o seguinte comando:

      • openssl req -in ~/certs/sammy.csr -noout -text

      Aqui, você envia o CSR com -in e usa -text para imprimir a solicitação de certificado em texto.

      O resultado mostrará a solicitação de certificado, cujo início se parecerá com este:

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Repita o mesmo procedimento para criar CSRs para quaisquer usuários adicionais. Assim que tiver todas as solicitações de assinatura de certificado salvas na pasta ~/certs do administrador, prossiga com o próximo passo para aprová-las.

      Como gerenciar pedidos de assinatura de certificado com a API do Kubernetes

      Você pode aprovar ou negar os certificados TLS emitidos para a API do Kubernetes usando a ferramenta de linha de comando kubectl. Isso dá a você a capacidade de garantir que o acesso solicitado é apropriado para um determinado usuário. Nesta seção, você enviará e aprovará a solicitação de certificado para sammy.

      Para enviar uma CSR para o cluster DOKS, use o seguinte comando:

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      Usando um here document Bash, este comando usa o cat para passar a solicitação de certificado para o kubectl apply.

      Vamos dar uma olhada de perto na solicitação de certificado:

      • name: sammy-authentication cria um identificador de metadados, neste caso chamado sammy-authentication.
      • request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n') envia a solicitação de assinatura de certificado sammy.csr para o cluster codificado como Base64.
      • server auth e client auth especificam o uso pretendido do certificado. Neste caso, o propósito é a autenticação de usuário.

      O resultado será semelhante a este:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Você pode verificar o status da solicitação de assinatura de certificado usando o comando:

      Dependendo da sua configuração de cluster, o resultado será semelhante a este:

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      Em seguida, aprove o CSR usando o comando:

      • kubectl certificate approve sammy-authentication

      Você receberá uma mensagem confirmando a operação:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Nota: como administrador, você também pode negar uma CSR usando o comando kubectl certificate deny sammy-authentication. Para obter mais informações sobre como gerenciar certificados TLS, leia a documentação oficial do Kubernetes.

      Agora que a CSR está aprovada, baixe-a para a máquina local, executando:

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Este comando decodifica o certificado Base64 para uso adequado pelo kubectl e, em seguida, salva-o como ~/certs/sammy.crt.

      Com o certificado sammy assinado em mãos, agora é possível construir o arquivo kubeconfig do usuário.

      Como construir o kubeconfig de usuários remotos

      Em seguida, você criará um arquivo kubeconfig específico para o usuário sammy. Isso dará mais controle sobre o acesso do usuário ao seu cluster.

      O primeiro passo na construção de um novo kubeconfig é fazer uma cópia do arquivo kubeconfig atual. Para os fins deste guia, o novo arquivo kubeconfig será chamado de config-sammy:

      • cp ~/.kube/config ~/.kube/config-sammy

      Em seguida, edite o novo arquivo:

      • nano ~/.kube/config-sammy

      Mantenha as primeiras oito linhas deste arquivo, uma vez que elas contêm as informações necessárias para a conexão SSL/TLS com o cluster. Então, começando a partir do parâmetro de user, substitua o texto pelas linhas destacadas a seguir, para que o arquivo seja semelhante ao seguinte:

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Nota: para o client-certificate e client-key, use o caminho absoluto para sua localização de certificado correspondente. Caso contrário, o kubectl gerará um erro.

      Salve e saia do arquivo.

      É possível testar a nova conexão de usuário usando kubectl cluster-info:

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Você verá um erro semelhante a este:

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Este erro é esperado, pois o usuário sammy ainda não tem permissão para listar qualquer recurso no cluster. Como conceder a autorização para usuários será abordado no próximo passo. Por enquanto, o resultado está confirmando que a conexão SSL/TLS foi bem-sucedida e as credenciais de autenticação sammy foram aceitas pela API do Kubernetes.

      Passo 2 — Autorizando usuários por meio do Controle de acesso baseado em papel (RBAC)

      Assim que um usuário for autenticado, a API determina as permissões dela usando o modelo de controle de acesso baseado em papel (RBAC) do Kubernetes. O RBAC é um método eficaz para restringir os direitos de usuário, baseando-se no papel atribuído a ele. De um ponto de vista de segurança, o RBAC permite configurar permissões de dados refinadas para limitar os usuários de acessar dados confidenciais ou executar comandos de superusuário. Para obter informações mais detalhadas sobre os papéis de usuário, consulte a documentação RBAC do Kubernetes.

      Neste passo, você usará o kubectl para atribuir o papel pré-definido edit para o usuário sammy no namespace default. Em um ambiente de produção, você pode querer usar papéis personalizados e/ou atribuições de papel personalizadas.

      Como conceder permissões

      No Kubernetes, conceder permissões significa atribuir o papel desejado a um usuário. Atribua permissões edit para o usuário sammy no namespace default usando o seguinte comando:

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Isso dará um resultado similar ao seguinte:

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Vamos analisar este comando em mais detalhes:

      • create rolebinding sammy-edit-role cria uma nova atribuição de papel, neste caso chamado sammy-edit-role.
      • --clusterrole=edit atribui o papel pré-definido edit em um escopo global (papel do cluster).
      • --user=sammy especifica a qual usuário vincular o papel.
      • --namespace=default concede ao usuário permissões de papel dentro do namespace especificado, neste caso, default.

      Em seguida, verifique as permissões de usuários listando os pods no namespace default. Você pode dizer que a autorização RBAC está funcionando como esperado se nenhum erro for mostrado.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Você receberá o seguinte resultado:

      Output

      yes

      Agora que você atribuiu permissões para sammy, pratique a revogação dessas permissões na seção seguinte.

      Como revogar permissões

      A revogação de permissões é feita no Kubernetes removendo o papel do usuário.

      Para este tutorial, delete o papel edit do usuário sammy, executando o seguinte comando:

      • kubectl delete rolebinding sammy-edit-role

      Você receberá o seguinte resultado:

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Verifique se as permissões de usuário foram revogadas como esperado listando os pods do namespace default:

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Você receberá o seguintes erro:

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Isso mostra que a autorização foi revogada.

      Do ponto de vista de segurança, o modelo de autorização do Kubernetes dá aos administradores de cluster a flexibilidade para alterar os direitos de usuários sob demanda, conforme necessário. Além disso, o controle de acesso baseado em papel não se limita a um usuário físico; você também pode conceder e remover permissões aos serviços de cluster, como aprenderá na seção seguinte.

      Para obter mais informações sobre a autorização RBAC e como criar papéis personalizados, leia a documentação oficial.

      Como mencionado na seção anterior, os mecanismos de autorização do RBAC se estendem para além de usuários humanos. Usuários de cluster não humanos, como aplicativos, serviços e processos em execução dentro de pods, autenticam-se com a API do servidor usando o que o Kubernetes chama de contas de serviço. Quando um pod é criado dentro de um namespace, você pode deixá-lo usar a conta de serviço default ou definir uma conta de serviço de sua escolha. A capacidade de atribuir CSs individuais aos aplicativos e processos dá aos administradores a liberdade de concessão ou revogação de permissões, conforme necessário. Além disso, atribuir CSs específicas para aplicativos críticos para a produção é considerada uma prática recomendada de segurança. Como usa-se contas de serviço para autenticação e, assim, para as checagens de autorização do RBAC, os administradores de clusters contém ameaças de segurança por meio da alteração de direitos de acesso de conta de serviço e isolamento do processo de ofensa.

      Para demonstrar contas de serviço, este tutorial usará um servidor Web do Nginx como um aplicativo de amostra.

      Antes de atribuir uma CS particular para seu aplicativo, é necessário criar a CS. Crie uma nova conta de serviço chamada nginx-sa no namespace default:

      • kubectl create sa nginx-sa

      Você receberá:

      Output

      serviceaccount/nginx-sa created

      Verifique se a conta de serviço foi criada executando o seguinte:

      Isso dará a você uma lista de suas contas de serviço:

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      Agora, você atribuirá um papel para a conta de serviço nginx-sa. Para este exemplo, conceda a nginx-sa as mesmas permissões que o usuário sammy:

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      Ao executar isso, obtêm-se o seguinte:

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      Esse comando usa o mesmo formato que para o usuário sammy, exceto pela flag --serviceaccount=default:nginx-sa, onde você atribui a conta de serviço nginx-sa no namespace default.

      Verifique se a vinculação de papel foi bem-sucedida usando este comando:

      Isso dará o seguinte resultado:

      Output

      NAME AGE nginx-sa-edit 23s

      Assim que tiver confirmado que a atribuição de papel para a conta de serviço foi configurada com sucesso, é possível atribuir a conta de serviço a um aplicativo. Atribuir uma conta de serviço particular para um aplicativo permitirá que você gerencie seus direitos de acesso em tempo real e, portanto, reforce a segurança do cluster.

      Para os fins deste tutorial, um pod nginx servirá como aplicativo de amostra. Crie o novo pod e especifique a conta de serviço nginx-sa com o seguinte comando:

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      A primeira parte do comando cria um novo pod que é executado no servidor Web nginx na porta :80, e a última porção --serviceaccount="nginx-sa" indica que este pod deve usar a conta de serviço nginx-sa e não a CS default.

      Isso gerará um resultado similar ao seguinte:

      Output

      deployment.apps/nginx created

      Verifique se o novo aplicativo está usando a conta de serviço, usando kubectl describe:

      • kubectl describe deployment nginx

      Isso gerará uma descrição longa dos parâmetros de implantação. Na seção Pod Template, você verá um resultado semelhante a este:

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      Nesta seção, você criou a conta de serviço nginx-sa no namespace default e a atribuiu ao servidor nginx. Agora, é possível controlar permissões do nginx em tempo real, modificando o papel dele conforme necessário. Também é possível agrupar aplicativos atribuindo a mesma conta de serviço a cada um e, em seguida, fazer alterações de maior peso na permissões. Por fim, seria possível isolar aplicativos críticos, atribuindo-lhes uma CS única.

      Resumindo, a ideia por trás da atribuição de papéis para seus aplicativos/implantações é ajustar em detalhes as permissões. Em ambientes de produção real, você pode ter várias implantações que requerem permissões diferentes, que vão desde apenas leitura até privilégios administrativos completos. Usar o RBAC traz a flexibilidade para restringir o acesso ao cluster conforme necessário.

      Em seguida, você configurará controladores de admissão para controlar recursos e protegê-los contra os ataques de esgotamento de recursos.

      Passo 4 — Configurando os controladores de admissão

      Os controladores de admissão do Kubernetes são plug-ins opcionais compilados no binário kube-apiserver para expandir as opções de segurança. Os controladores de admissão interceptam solicitações após elas passarem a fase de autenticação e autorização. Assim que a solicitação é interceptada, os controladores de admissão executam o código especificado pouco antes da solicitação ser aplicada.

      Embora o resultado de uma verificação de autenticação ou autorização seja um booleano que permite ou nega a solicitação, os controladores de admissão podem ser muito mais variados. Os controladores de admissão podem validar solicitações da mesma forma que a autenticação, mas também podem alterar ou mudar os pedidos e modificar os objetos antes de serem admitidos.

      Neste passo, você usará os controladores de admissão ResourceQuota e LimitRange para proteger seu cluster, mudando solicitações que poderiam contribuir para um ataque de esgotamento de recursos ou de negação de serviço. O controlador de admissão ResourceQuota permite que os administradores restrinjam os recursos de computação, recursos de armazenamento e a quantidade de qualquer objeto dentro de um namespace, ao passo que o controlador de admissão LimitRange limitará o número de recursos usados pelos contêineres. Usar esses dois controladores de admissão juntos protegerá seu cluster de ataques que tornariam seus recursos indisponíveis.

      Para demonstrar como funciona o ResourceQuota, você implementará algumas restrições no namespace default. Comece criando um novo arquivo de objeto do ResourceQuota:

      • nano resource-quota-default.yaml

      Adicione a definição de objeto a seguir no conjunto de restrições para o consumo de recursos no namespace default. Você pode ajustar os valores conforme necessário, dependendo dos recursos físicos dos seus nós:

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      Esta definição usa a palavra-chave hard para definir restrições severas, como o número máximo de pods, configmaps, PersistentVolumeClaims, ReplicationControllers, secrets, services e loadbalancers. Ela também define os limites dos recursos de computação, como:

      • requests.cpu, que define o valor máximo de CPU dos pedidos em milliCPU, ou um milésimo de um núcleo da CPU.
      • requests.memory, que define o valor máximo de memória dos pedidos em bytes.
      • limits.cpu, que define o valor máximo de CPU dos limites em milliCPUs.
      • limits.memory, que define o valor máximo de memória dos limites em bytes.

      Salve e saia do arquivo.

      Agora, crie o objeto no namespace, executando o seguinte comando:

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Isso irá resultar no seguinte:

      Output

      resourcequota/resource-quota-default created

      Note que você está usando a flag -f para indicar ao Kubernetes o local do arquivo ResourceQuota e a flag --namespace para especificar qual espaço de nomes será atualizado.

      Assim que o objeto for criado, seu ResourceQuota estará ativo. Você pode verificar as quotas do namespace default com describe quota:

      • kubectl describe quota --namespace=default

      O resultado será semelhante a este, com os limites severos que você definiu no arquivo resource-quota-default.yaml:

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      ResourceQuotas são expressos em unidades absolutas, então, adicionar nós adicionais não aumentará automaticamente os valores definidos aqui. Se mais nós forem adicionados, você precisará editar manualmente os valores aqui para providenciar os recursos. ResourceQuotas podem ser modificados sempre que precisar, mas não podem ser removidos, a menos que todo o namespace seja removido.

      Se precisar modificar um ResourceQuota em particular, atualize o arquivo .yaml correspondente e aplique as alterações usando o seguinte comando:

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Para obter mais informações sobre o controlador de admissão ResourceQuota, consulte a documentação oficial.

      Agora que seu ResourceQuota está configurado, continue adiante para configurar o controlador de admissão LimitRange. De maneira similar a como o ResourceQuota aplica limites nos namespaces, o LimitRange aplica as limitações declaradas, pela validação e alteração de contêineres.

      De forma parecida como feito antes, comece criando o arquivo de objeto:

      • nano limit-range-default.yaml

      Agora, utilize o objeto LimitRange para restringir o uso de recursos conforme necessário. Adicione o conteúdo a seguir como exemplo de um caso de uso típico:

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Os valores amostrais usados em limit-ranges-default.yaml restringem a memória do contêiner a um máximo de 1Gi e limita o uso de CPU a um máximo de 400m, que é equivalente a 400 milliCPU, o que significa que o contêiner fica limitado a usar quase metade do seu núcleo.

      Em seguida, implante o objeto no servidor da API, usando o seguinte comando:

      • kubectl create -f limit-range-default.yaml --namespace=default

      Isso dará o seguinte resultado:

      Output

      limitrange/limit-range-default created

      Agora, verifique os novos limites com o seguinte comando:

      • kubectl describe limits --namespace=default

      Seu resultado será semelhante a este:

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Para ver o LimitRanger em ação, implante um contêiner nginx padrão com o seguinte comando:

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Isso dará o seguinte resultado:

      Output

      pod/nginx created

      Note como o controlador de admissão transformou o contêiner, executando o seguinte comando:

      • kubectl get pod nginx -o yaml

      Isso gerará muitas linhas como resultado. Procure na seção de especificação do contêiner para encontrar os limites de recurso especificados no controlador de admissão LimitRange:

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Seria a mesma coisa caso tivesse declarado manualmente os resources e requests na especificação do contêiner.

      Neste passo, você usou os controladores de admissão ResourceQuota e LimitRange para se proteger contra ataques mal-intencionados que visam os recursos do seu cluster. Para obter mais informações sobre o controlador de admissão LimitRange, leia a documentação oficial.

      Conclusão

      Ao longo deste guia, você configurou um modelo de segurança do Kubernetes básico. Ele estabeleceu a autenticação e a autorização do usuário, privilégios de aplicativo e proteção de recursos do cluster. Pela combinação de todas as sugestões abrangidas neste artigo, você terá uma base sólida para uma implantação de cluster do Kubernetes na produção. A partir daí, você pode começar a solidificar outros aspectos individuais do seu cluster, dependendo do seu cenário.

      Se quiser aprender mais sobre o Kubernetes, confira nossa página de recursos do Kubernetes, ou siga nosso curso auto-guiado Kubernetes para desenvolvedores full-stack.



      Source link

      Pasos recomendados para proteger un clúster de Kubernetes de DigitalOcean


      El autor seleccionó Open Sourcing Mental Illness para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Kubernetes, la plataforma de orquestación de contenedores de código abierto, se está convirtiendo en la solución preferida para automatizar, escalar y administrar clústeres de alta disponibilidad. Como resultado de su creciente popularidad, la seguridad en ella se ha vuelto cada vez más relevante.

      Tomando en cuenta los elementos móviles que intervienen en Kubernetes y la variedad de escenarios de implementación, proteger Kubernetes a veces puede ser un proceso complejo. Debido a esto, el objetivo de este artículo es proporcionar una base de seguridad sólida para un clúster de Kubernetes de DigitalOcean (DOKS). Tenga en cuenta que este tutorial contempla las medidas básicas de seguridad para Kubernetes y está pensado para ser un punto de partida más que una guía exhaustiva. Para hallar pasos adicionales, consulte la documentación oficial de Kubernetes.

      A través de esta guía, completará pasos básicos para proteger su clúster de Kubernetes de DigitalOcean. Configurará la autenticación local segura con certificados TLS y SSL, concederá permisos a los usuarios locales con controles de acceso basados en roles (RBAC), concederá permisos a aplicaciones e implementaciones de Kubernetes con cuentas de servicio y establecerá límites de recursos con los controladores de admisión ResourceQuota y LimitRange.

      Requisitos previos

      Para completar este tutorial, necesitará lo siguiente:

      • Un clúster administrado por DigitalOcean de Kubernetes (DOKS) con 3 nodos estándares configurados cada uno con al menos 2 GB de RAM y 1 vCPU. Para hallar instrucciones detalladas sobre cómo crear un clúster DOKS, consulte nuestra guía de inicio rápido de Kubernetes. En este tutorial se utiliza DOKS 1.16.2-do.1.
      • Un cliente local configurado para administrar el clúster DOKS, con un archivo de configuración de clúster descargado del panel de control de DigitalOcean y guardado como ~/.kube/config. Para hallar instrucciones detalladas sobre cómo configurar la administración remota de DOKS, lea nuestra guía Cómo establecer conexión con un clúster de Kubernetes de DigitalOcean. En particular, necesitará lo siguiente:
        • La interfaz de línea de comandos kubectl instalada en su computadora local. Puede obtener más información sobre cómo instalar y configurar kubectl en su documentación oficial. En este tutorial, usaremos la versión 1.17.0-00 de kubectl.
        • La herramienta de línea de comandos oficial de DigitalOcean, doctl. Para hallar instrucciones sobre cómo instalar esto, consulte la página sobre doctl de GitHub. En este tutorial, se usará la versión 1.36.0 de doctl.

      Paso 1: Habilitar la autenticación remota de usuarios

      Una vez completados los requisitos previos, obtendrá un superusuario de Kubernetes que se autentica a través de un token de portador de DigitalOcean predefinido. Sin embargo, compartir esas credenciales no es una práctica de seguridad recomendada, ya que en esta cuenta se pueden ocasionar cambios a gran escala y posiblemente destructivos para su clúster. Para reducir esta posibilidad, puede configurar usuarios adicionales que se autentiquen desde sus respectivos clientes locales.

      En esta sección, autenticará nuevos usuarios en el clúster DOKS remoto de los clientes locales usando certificados SSL y TLS seguros. Será un proceso de tres pasos: primero, creará solicitudes de firma de certificados (CSR) para cada usuario. Luego, aprobará esos certificados directamente en el clúster a través de kubectl. Por último, creará para cada usuario un archivo kubeconfig con los certificados correspondientes. Para obtener más información sobre los métodos de autenticación adicionales compatibles con Kubernetes, consulte la documentación de autenticación de Kubernetes.

      Crear solicitudes de firma de certificados para nuevos usuarios

      Antes de comenzar, compruebe la conexión del clúster DOKS desde la máquina local configurada en los requisitos previos:

      Dependiendo de su configuración, el resultado será similar a este:

      Output

      Kubernetes master is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com CoreDNS is running at https://a6616782-5b7f-4381-9c0f-91d6004217c7.k8s.ondigitalocean.com/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

      Esto significa que está conectado al clúster DOKS.

      A continuación, cree una carpeta local para los certificados de cliente. A los efectos de esta guía, se usará ~/certs para almacenar todos los certificados:

      En este tutorial, para acceder al clúster autorizaremos un nuevo usuario llamado sammy. Puede cambiarlo por un usuario que elija. Usando la biblioteca OpenSSL de SSL y TLS, genere una nueva clave privada para su usuario con el siguiente comando:

      • openssl genrsa -out ~/certs/sammy.key 4096

      Con el indicador -out se creará el archivo de salida ~/certs/sammy.key, y con 4096 se fija la clave en 4096 bits. Para obtener más información sobre OpenSSL, consulte nuestra guía Aspectos básicos de OpenSSL.

      A continuación, cree un archivo de configuración de la solicitud de firma de certificados. Abra el siguiente archivo con un editor de texto (para este tutorial, usaremos nano):

      • nano ~/certs/sammy.csr.cnf

      Añada el siguiente contenido al archivo sammy.csr.cnf para especificar en el tema el nombre de usuario deseado como nombre común (CN) y el grupo como organización (O):

      ~/certs/sammy.csr.cnf

      [ req ]
      default_bits = 2048
      prompt = no
      default_md = sha256
      distinguished_name = dn
      [ dn ]
      CN = sammy
      O = developers
      [ v3_ext ]
      authorityKeyIdentifier=keyid,issuer:always
      basicConstraints=CA:FALSE
      keyUsage=keyEncipherment,dataEncipherment
      extendedKeyUsage=serverAuth,clientAuth
      

      En el archivo de configuración de la solicitud de firma de certificados se incluyen toda la información necesaria, la identidad del usuario y los parámetros de uso adecuados para el usuario. El ltimo argumento extendedKeyUsage=serverAuth,clientAuth permitirá que los usuarios autentiquen sus clientes locales con el clúster DOKS usando el certificado una vez que se haya firmado.

      A continuación, cree la solicitud de firma de certificados sammy:

      • openssl req -config ~/certs/sammy.csr.cnf -new -key ~/certs/sammy.key -nodes -out ~/certs/sammy.csr

      Con -config se le permite especificar el archivo de configuración para la CSR, y -new indica que creará una nueva CSR para la clave especificada por -key.

      Puede verificar la solicitud de firma de certificados ejecutando el siguiente comando:

      • openssl req -in ~/certs/sammy.csr -noout -text

      Se pasa la CSR con -in y se utiliza -text para imprimir la solicitud del certificado en texto.

      En el resultado, se mostrará la solicitud del certificado, cuyo comienzo tendrá un aspecto similar a este:

      Output

      Certificate Request: Data: Version: 1 (0x0) Subject: CN = sammy, O = developers Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (4096 bit) ...

      Repita el mismo procedimiento para crear CSR para cualquier usuario adicional. Una vez que tenga todas las solicitudes de firma de certificados guardadas en la carpeta del administrador ~/certs, proceda con el paso siguiente para aprobarlas.

      Administrar solicitudes de firma de certificados con la API de Kubernetes

      Puede aprobar o negar certificados TLS emitidos para la API de Kubernetes usando la herramienta de línea de comandos kubectl. Con esto, tendrá la capacidad de garantizar que el acceso solicitado sea apropiado para el usuario en cuestión. En esta sección, enviará la solicitud de certificado para sammy y la aprobará.

      Para enviar una CSR al clúster DOKS, utilice el siguiente comando:

      cat <<EOF | kubectl apply -f -
      apiVersion: certificates.k8s.io/v1beta1
      kind: CertificateSigningRequest
      metadata:
        name: sammy-authentication
      spec:
        groups:
        - system:authenticated
        request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n')
        usages:
        - digital signature
        - key encipherment
        - server auth
        - client auth
      EOF
      

      Mediante un here document de Bash, este comando utiliza cat para pasar la solicitud de certificado a kubectl apply.

      Veamos con más detalle la solicitud de certificado:

      • Con name: sammy-authentication, se crea un identificador de metadatos llamado en este caso sammy-authentication.
      • Con request: $(cat ~/certs/sammy.csr | base64 | tr -d 'n') se envía la solicitud de firma de certificados sammy.csr al clúster, codificado como base64.
      • Con server auth y client auth se especifica el uso previsto del certificado. En este caso, el propósito es autenticar el usuario.

      El resultado tendrá un aspecto similar a este:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication created

      Puede verificar el estado de la solicitud de firma de certificados usando el siguiente comando:

      Dependiendo de la configuración de su clúster, el resultado será similar a este:

      Output

      NAME AGE REQUESTOR CONDITION sammy-authentication 37s your_DO_email Pending

      A continuación, apruebe la CSR usando el siguiente comando:

      • kubectl certificate approve sammy-authentication

      Verá un mensaje que confirmará la operación:

      Output

      certificatesigningrequest.certificates.k8s.io/sammy-authentication approved

      Nota: Como administrador, también puede negar una CSR usando el comando kubectl certificate deny sammy-authentication. Para obtener más información sobre la administración de certificados TLS, consulte la documentación oficial de Kubernetes.

      Ahora que se aprobó la CSR, puede descargarla a la máquina local ejecutando lo siguiente:

      • kubectl get csr sammy-authentication -o jsonpath='{.status.certificate}' | base64 --decode > ~/certs/sammy.crt

      Con este comando, se decodifica el certificado de Base64 para que kubectl lo use correctamente; luego se guarda como ~/certs/sammy.crt.

      Una vez firmado el el certificado sammy, podrá crear el archivo kubeconfig del usuario.

      Crear Kubeconfig para usuarios remotos

      A continuación, creará un archivo kubeconfig específico para el usuario sammy. Esto le proporcionará más control sobre el acceso del usuario a su clúster.

      El primer paso para crear un nuevo kubeconfig es hacer una copia del archivo kubeconfig actual. A los efectos de esta guía, el nuevo archivo kubeconfig recibirá el nombre config-sammy:

      • cp ~/.kube/config ~/.kube/config-sammy

      A continuación, edite el nuevo archivo:

      • nano ~/.kube/config-sammy

      Conserve las primeras ocho líneas de este archivo, ya que contienen la información necesaria para la conexión SSL y TLS con el clúster. Luego, empezando por el parámetro de user, sustituya el texto por las siguientes líneas resaltadas de modo que el archivo tenga un aspecto similar al siguiente:

      config-sammy

      apiVersion: v1
      clusters:
      - cluster:
          certificate-authority-data: certificate_data
        name: do-nyc1-do-cluster
      contexts:
      - context:
          cluster: do-nyc1-do-cluster
          user: sammy
        name: do-nyc1-do-cluster
      current-context: do-nyc1-do-cluster
      kind: Config
      preferences: {}
      users:
      - name: sammy
        user:
          client-certificate: /home/your_local_user/certs/sammy.crt
          client-key: /home/your_local_user/certs/sammy.key
      

      Nota: Tanto para client-certificate como client-key, utilice la ruta absoluta hacia las ubicaciones de sus certificados correspondientes. De lo contrario, en kubectl se producirá un error.

      Guarde el archivo y ciérrelo.

      Puede probar la conexión del usuario nuevo usando kubectl cluster-info:

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy cluster-info

      Verá un error similar a este:

      Output

      To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. Error from server (Forbidden): services is forbidden: User "sammy" cannot list resource "services" in API group "" in the namespace "kube-system"

      Este error se espera, ya que el usuario sammy no tiene autorización para enumerar ningún recurso en el clúster. En el siguiente paso, se cubrirá la concesión de autorización a los usuarios. Por ahora, en el resultado se confirma que la conexión SSL y TLS fue exitosa y la API de Kubernetes aceptó las credenciales de autenticación de sammy.

      Paso 2: Autorizar usuarios a través del control de acceso basado en roles (RBAC)

      Una vez que un usuario se autentica, en la API se determinan sus permisos usando el modelo integrado de control de acceso basado en roles (RBAC) de Kubernetes. El RBAC es un método eficaz para restringir derechos de usuarios en función del rol asignado. Desde el punto de vista de la seguridad, con RBAC se permite la personalización avanzada de permisos para limitar, en el caso de los usuarios, el acceso a datos confidenciales o la ejecución de comandos en el nivel del superusuario. Para obtener más información sobre los roles de usuario, consulte la documentación de RBAC de Kubernetes.

      En este paso, usará kubectl para asignar el rol predefinido edit al usuario sammy en el espacio de nombres default. En un entorno de producción, es posible que quiera usar roles personalizados o vinculaciones de estos roles.

      Conceder permisos

      En Kubernetes, conceder permisos implica asignar el rol deseado a un usuario. Asigne los permisos edit al usuario sammy en el espacio de nombres default usando el siguiente comando:

      • kubectl create rolebinding sammy-edit-role --clusterrole=edit --user=sammy --namespace=default

      Con esto, se mostrará un resultado similar al siguiente:

      Output

      rolebinding.rbac.authorization.k8s.io/sammy-edit-role created

      Analizaremos este comando en mayor detalle:

      • Con create rolebinding sammy-edit-role se crea un nueva vinculación de rol, en este caso llamada sammy-edit-role.
      • Con --clusterrole=edit se asigna el rol predefinido edit en un ámbito global (rol de clúster).
      • Con --user=sammy se especifica el usuario con el que se vinculará el rol.
      • Con --namespace=default se conceden al usuario los permisos del rol dentro del espacio de nombres especificado; en este caso, default.

      A continuación, verifique los permisos del usuario enumerando pods en el espacio de nombres default. Puede comprobar si la autorización de RBAC funciona como se espera si no se muestran errores.

      • kubectl --kubeconfig=/home/your_local_user/.kube/config-sammy auth can-i get pods

      Verá el siguiente resultado:

      Output

      yes

      Ahora que asignó permisos a sammy, en la siguiente sección puede practicar la revocación de esos permisos.

      Revocar permisos

      La revocación de permisos en Kubernetes se realiza eliminando la vinculación de rol del usuario.

      Para este tutorial, elimine el rol edit del usuario sammy ejecutando el siguiente comando:

      • kubectl delete rolebinding sammy-edit-role

      Verá el siguiente resultado:

      Output

      rolebinding.rbac.authorization.k8s.io "sammy-edit-role" deleted

      Verifique si los permisos del usuario se revocaron como se esperaba enumerando los pods del espacio de nombres default:

      • kubectl --kubeconfig=/home/localuser/.kube/config-sammy --namespace=default get pods

      Obtendrá el siguiente error:

      Output

      Error from server (Forbidden): pods is forbidden: User "sammy" cannot list resource "pods" in API group "" in the namespace "default"

      Esto muestra que se revocó la autorización.

      Desde el punto de vista de la seguridad, con el modelo de autorización de Kubernetes se brinda a los administradores la flexibilidad necesaria para cambiar los derechos de los usuarios a pedido, según sea necesario. Además, el control de acceso basado en roles no se limita a un usuario físico; también puede conceder y eliminar permisos a servicios de clústeres, como se explicará en la siguiente sección.

      Para obtener más información sobre la autorización de RBAC y la manera de crear roles personalizados, consulte la documentación oficial.

      Paso 3: Administrar permisos de aplicación con cuentas de servicio

      Como se mencionó en la sección anterior, los mecanismos de autorización de RBAC van más allá de los usuarios humanos. Los usuarios de clústeres no humanos, como las aplicaciones, los servicios y los procesos que se ejecutan dentro de pods, se autentican con el servidor de API usando lo que en Kubernetes se conoce como cuentas de servicio. Cuando se crea un pod dentro de un espacio de nombres, puede permitir que se utilice la cuenta de servicio default o definir una cuenta de servicio que elija. La capacidad de asignar cuentas de servicio individuales a aplicaciones y procesos brinda a los administradores la libertad de conceder o revocar permisos según sea necesario. Además, se considera una buena práctica de seguridad asignar cuentas de servicio específicas a aplicaciones críticas para la producción. Debido a que las cuentas de servicio (SA) se utilizan para la autenticación, y por lo tanto para realizar comprobaciones de autorización de RBAC, los administradores de clústeres pueden contener las amenazas de seguridad cambiando los derechos de acceso de las cuentas de servicio y aislando el proceso delictivo.

      Para ofrece una demostración de las SA, en este tutorial utilizaremos un servidor web Nginx como una aplicación de ejemplo.

      Antes de asignar una SA en particular a su aplicación, deberá crear dicha SA. Cree una nueva cuenta de servicio llamada nginx-sa en el espacio de nombres default:

      • kubectl create sa nginx-sa

      Obtendrá este resultado:

      Output

      serviceaccount/nginx-sa created

      Verifique que la cuenta de servicio se haya creado ejecutando lo siguiente:

      Esto le proporcionará una lista de sus cuentas de servicios:

      Output

      NAME SECRETS AGE default 1 22h nginx-sa 1 80s

      A continuación, asignará un rol a la cuenta de servicio nginx-sa. Para este ejemplo, conceda a nginx-sa los mismos permisos que al usuario sammy:

      • kubectl create rolebinding nginx-sa-edit
      • --clusterrole=edit
      • --serviceaccount=default:nginx-sa
      • --namespace=default

      Al ejecutar esto, obtendrá el siguiente resultado:

      Output

      rolebinding.rbac.authorization.k8s.io/nginx-sa-edit created

      En este comando se utiliza el mismo formato que para el usuario sammy, a excepción del indicador --serviceaccount=default:nginx-sa, donde asigna la cuenta de servicio nginx-sa en el espacio de nombres default.

      Compruebe que la vinculación del rol se haya realizado correctamente usando este comando:

      Esto generará el siguiente resultado:

      Output

      NAME AGE nginx-sa-edit 23s

      Una vez que haya confirmado que la vinculación del rol para la cuenta del servicio se configuró correctamente, podrá asignar la cuenta de servicio a una aplicación. Asignar una cuenta de servicio particular a una aplicación le permitirá administrar sus derechos de acceso en tiempo real y, por lo tanto, mejorar la seguridad del clúster.

      A los efectos de este tutorial, un pod de nginx servirá como la aplicación de muestra. Cree el nuevo pod y especifique la cuenta de servicio nginx-sa con el siguiente comando:

      • kubectl run nginx --image=nginx --port 80 --serviceaccount="nginx-sa"

      En la primera parte del comando se crea un nuevo pod ejecutando un servidor web nginx en el puerto :80, y en la última parte en --serviceaccount="nginx-sa" se indica que en este pod se debe usar la cuenta de usuarionginx-sa y no la SA default.

      Con esto, se mostrará un resultado similar al siguiente:

      Output

      deployment.apps/nginx created

      Verifique que en la nueva aplicación se utilice la cuenta de servicio usando kubectl describe:

      • kubectl describe deployment nginx

      Con esto se mostrará una descripción extensa de los parámetros de implementación. En la sección de Pod Template, verá un resultado similar al siguiente:

      Output

      ... Pod Template: Labels: run=nginx Service Account: nginx-sa ...

      En esta sección, creó la cuenta de servicio nginx-sa en el espacio de nombres default y la asignó al servidor web nginx. Ahora puede controlar los permisos de nginx en tiempo real cambiando sus roles según sea necesario. También puede agrupar aplicaciones asignando la misma cuenta de servicio a cada una y luego aplicar cambios en bloque a los permisos. Finalmente, puede aislar aplicaciones críticas asignándoles una cuenta de usuario única.

      En resumen, la idea de asignar roles a sus aplicaciones e implementaciones es ajustar los permisos. En los entornos de producción reales, es posible que tenga varias implementaciones que requieran diferentes permisos, que abarcan desde privilegios de solo lectura a privilegios administrativos completos. Con el uso del RBAC se le proporciona la flexibilidad necesaria para restringir el acceso al clúster según sea necesario.

      A continuación, establecerá los controladores de admisión para controlar los recursos y protegerse de los ataques de agotamiento de recursos.

      Paso 4: Configurar controladores de admisión

      Los controladores de admisión de Kubernetes son complementos opcionales que se compilan en el binario kube-apiserver para ampliar las opciones de seguridad. Los controladores de admisión interceptan solicitudes una vez que superan la fase de autenticación y autorización. Cuando interceptan una solicitud, los controladores de admisión ejecutan el código especificado justo antes de que esta se aplique.

      Si bien el resultado de una verificación de autenticación o autorización es un booleano con el que se permite o deniega la solicitud, los controladores de admisión pueden ser mucho más diversos. Los controladores de admisión pueden validar las solicitudes de la misma forma que la autenticación, pero también pueden mutar o cambiar las solicitudes y modificar los objetos antes de su admisión.

      En este paso, usará los controladores de admisión ResourceQuota y LimitRange para proteger su clúster mediante la mutación de las solicitudes que podrían contribuir a un ataque de agotamiento de recursos o denegación de servicio. Con el controlador de admisión ResourceQuota se permite a los administradores restringir los recursos informáticos y de almacenamiento, y la cantidad de cualquier objeto dentro de un espacio de nombres, mientras que el controlador de admisión LimitRange limita el número de recursos que los contenedores utilizan. Utilizar estos dos controladores de admisión juntos protegerá su clúster contra ataques que hacen que sus recursos no estén disponibles.

      Para demostrar cómo funciona ResourceQuota, implementará algunas restricciones en el espacio de nombres default. Comience creando un nuevo archivo de objeto ResourceQuota:

      • nano resource-quota-default.yaml

      Añada la siguiente definición de objeto para establecer restricciones para el consumo de recursos en el espacio de nombres default. Puede ajustar los valores según sea necesario dependiendo de los recursos físicos de sus nodos:

      resource-quota-default.yaml

      apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: resource-quota-default
      spec:
        hard:
          pods: "2"
          requests.cpu: "500m"
          requests.memory: 1Gi
          limits.cpu: "1000m"
          limits.memory: 2Gi
          configmaps: "5"
          persistentvolumeclaims: "2"
          replicationcontrollers: "10"
          secrets: "3"
          services: "4"
          services.loadbalancers: "2"
      

      En esta definición se utiliza la palabra clave hard para establecer restricciones estrictas, como el número máximo de pods, configmaps, PersistentVolumeClaims, ReplicationControllers, secrets, services y loadbalancers. Con esto también se establecen restricciones en los recursos de proceso, como las siguientes:

      • requests.cpu fija el valor de CPU máximo de solicitudes en milliCPU o una milésima parte de un núcleo de CPU.
      • requests.memory fija el valor de memoria máximo de solicitudes en bytes.
      • limits.cpu fija el valor máximo de CPU de los límites en milliCPU.
      • limits.memory fija el valor máximo de memoria de los límites en bytes.

      Guarde el archivo y ciérrelo.

      Ahora, cree el objeto en el espacio de nombres ejecutando el siguiente comando:

      • kubectl create -f resource-quota-default.yaml --namespace=default

      Obtendrá el siguiente resultado:

      Output

      resourcequota/resource-quota-default created

      Tenga en cuenta que usará el indicador -f para marcar en Kubernetes la ubicación del archivo ResourceQuota y el indicador --namespace para especificar el espacio de nombres que se actualizará.

      Una vez creado el objeto, ResourceQuota estará activo. Puede verificar las cuotas del espacio de nombres default con describe quota:

      • kubectl describe quota --namespace=default

      El resultado será similar al siguiente, con los límites estrictos que estableció en el archivo resource-quota-default.yaml:

      Output

      Name: resource-quota-default Namespace: default Resource Used Hard -------- ---- ---- configmaps 0 5 limits.cpu 0 1 limits.memory 0 2Gi persistentvolumeclaims 0 2 pods 1 2 replicationcontrollers 0 10 requests.cpu 0 500m requests.memory 0 1Gi secrets 2 3 services 1 4 services.loadbalancers 0 2

      Las ResourceQuotas se expresan en unidades absolutas. Por ello, añadir nodos no aumentará automáticamente los valores definidos aquí. Si se añaden nodos, deberá editar manualmente los valores aquí para equilibrar los recursos. Las ResourceQuotas pueden modificarse tanta veces como lo necesite, pero no pueden eliminarse a menos que se quite todo el espacio de nombres.

      Si necesita modificar una ResourceQuota en particular, actualice el archivo .yaml correspondiente y aplique los cambios usando el siguiente comando:

      • kubectl apply -f resource-quota-default.yaml --namespace=default

      Para obtener más información sobre el controlador de admisión ResourceQuota, consulte la documentación oficial.

      Ahora que su ResourceQuota está establecido, procederá con la configuración del controlador de admisión LimitRange. Así como ResourceQuota impone límites para los espacios de nombres, de forma similar LimitRange aplica las limitaciones declaradas validando y mutando contenedores.

      Siguiendo un procedimiento similar al que usó antes, comience creando el archivo objeto:

      • nano limit-range-default.yaml

      Ahora, puede usar el objeto LimitRange para restringir el uso de recursos según sea necesario. Añada el siguiente contenido como ejemplo de un caso de uso típico:

      limit-ranges-default.yaml

      apiVersion: v1
      kind: LimitRange
      metadata:
        name: limit-range-default
      spec:
        limits:
        - max:
            cpu: "400m"
            memory: "1Gi"
          min:
            cpu: "100m"
            memory: "100Mi"
          default:
            cpu: "250m"
            memory: "800Mi"
          defaultRequest:
            cpu: "150m"
            memory: "256Mi"
          type: Container
      

      Con los valores de ejemplo utilizados en limit-ranges-default.yaml se restringe la memoria del contenedor a un máximo de 1Gi y se limita el uso del CPU a un máximo de 400m, lo cual es una métrica de Kubernetes equivalente a 400 milliCPU. Esto implica que el uso del contenedor se limita a casi la mitad de su núcleo.

      A continuación, implemente el objeto en el servidor de API usando el siguiente comando:

      • kubectl create -f limit-range-default.yaml --namespace=default

      Esto generará el siguiente resultado:

      Output

      limitrange/limit-range-default created

      Ahora puede verificar los nuevos límites con el siguiente comando:

      • kubectl describe limits --namespace=default

      El resultado tendrá un aspecto similar a este:

      Output

      Name: limit-range-default Namespace: default Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 100m 400m 150m 250m - Container memory 100Mi 1Gi 256Mi 800Mi -

      Para ver LimitRanger en acción, implemente un contenedor estándar nginx con el siguiente comando:

      • kubectl run nginx --image=nginx --port=80 --restart=Never

      Esto generará el siguiente resultado:

      Output

      pod/nginx created

      Ejecutando el siguiente comando, compruebe la forma en que el controlador de admisión mutó el contenedor:

      • kubectl get pod nginx -o yaml

      Esto generará muchas líneas de resultado. Busque en la sección de especificaciones de los contenedores para encontrar los límites de recursos especificados en el controlador de admisión LimitRange.

      Output

      ... spec: containers: - image: nginx imagePullPolicy: IfNotPresent name: nginx ports: - containerPort: 80 protocol: TCP resources: limits: cpu: 250m memory: 800Mi requests: cpu: 150m memory: 256Mi ...

      Esto sería lo mismo que declarar manualmente resources y requests en la especificación del contenedor.

      En este paso, usó los controladores de admisión ResourceQuota y LimitRange para protegerse de los ataques malintencionados contra los recursos de su clúster. Para obtener más información sobre el controlador de admisión LimitRange, consulte la documentación oficial.

      Conclusión

      A través de esta guía, configuró una plantilla básica de seguridad de Kubernetes. Con esto, se establecieron la autenticación y autorización de usuarios, los privilegios de aplicaciones y la protección de los recursos de clústeres. Combinando todas las sugerencias de este artículo, tendrá una base sólida para una implementación de un clúster de Kubernetes de producción. A partir de ahí, puede comenzar a reforzar aspectos individuales de su clúster dependiendo de su escenario.

      Si desea obtener más información sobre Kubernetes, consulte nuestra página de recursos de Kubernetes o complete nuestro curso de aprendizaje por cuenta propia de Kubernetes para desarrolladores “full-stack”.



      Source link