Configurar o mTLS nativo do Cassandra

Introdução

Diferentes componentes do Edge para nuvem privada, como processadores de mensagens, servidores de gerenciamento e roteadores, se conectam por um canal de texto simples aos nós do Cassandra por padrão. Nesses canais, os dados de e para o Cassandra são comunicados de forma clara. O mTLS da Apigee é um recurso baseado em malha de serviço do Consul que adiciona segurança às comunicações entre componentes no cluster do Edge para nuvem privada. Essa oferta da Apigee também adiciona segurança TLS ao canal de comunicação entre os componentes do cliente e o Cassandra.

Este artigo aborda uma nova oferta alternativa da Apigee em que a comunicação entre os componentes do cliente e o Cassandra no Edge para nuvem privada é protegida por TLS mútuo (também conhecido como TLS bidirecional) usando recursos disponíveis nativamente no Cassandra sem usar uma malha de serviço externa.

Recurso mTLS nativo

A ativação do mTLS entre o Cassandra e os componentes do cliente descritos neste artigo depende dos recursos TLS fornecidos nativamente pelo Apache Cassandra. Quando ativadas, as conexões de cliente com o Cassandra (na porta de transporte nativa do CQL 9042) realizam um handshake de TLS bidirecional com os clientes antes de permitir que as conexões sejam estabelecidas. Para fins dessa conexão TLS bidirecional, o Cassandra atua como servidor e vários clientes que se conectam ao Cassandra (como o processador de mensagens de borda, a ferramenta cqlsh etc.) atuam como clientes.

Para TLS bidirecional (ou TLS mútuo ou mTLS), o Cassandra e os clientes precisam ser configurados com o próprio keystore. O keystore de cada nó do Cassandra precisa conter a própria chave e certificado. O keystore de cada aplicativo cliente precisa conter a chave e o certificado desse cliente específico. Um truststore que contém os certificados e a cadeia associada da contraparte precisa ser adicionado ao Cassandra e aos clientes. O truststore de cada nó do Cassandra precisa conter certificados de clientes, e o truststore de cada cliente precisa conter certificados de todos os nós do Cassandra. Consulte o artigo TLS/SSL bidirecional da Apigee para mais informações sobre como um handshake de TLS bidirecional funciona.

Encadeamento de certificados

Geralmente, no TLS bidirecional, os certificados de servidor, os certificados do cliente, as cadeias de certificados, os keystores e os truststores podem ser criados de várias maneiras. O mesmo vale para o mTLS nativo do Cassandra e do cliente. Considerando como as organizações normalmente operam clusters do Edge para nuvem privada e o número de pares de conexão exclusivos de cliente para Cassandra que podem ser estabelecidos, a Apigee recomenda adotar a seguinte abordagem geral para configurar chaves e certificados para esse recurso. Há outros métodos viáveis, mas o método abaixo provavelmente oferece um bom equilíbrio entre segurança e sobrecarga de manutenção.

  1. Adquira um certificado raiz e um par de chave/certificado intermediário assinado pela raiz. Talvez você já tenha essas chaves e certificados. Caso contrário, crie certificados e chaves raiz e intermediários autoassinados seguindo as etapas no Apêndice 1.

  2. Use a chave/certificado intermediário comum acima para assinar todas as chaves e certificados específicos do aplicativo (folha).

Ter uma chave/certificado intermediário comum em um cluster faz com que um truststore comum (que contém a mesma cadeia de certificados raiz e intermediária) seja configurado em todos os nós do Cassandra e do cliente. Cada nó do Cassandra e aplicativo cliente recebe a própria chave e certificado de folha exclusivos assinados pela chave/certificado intermediário comum.

  1. A rotação de um certificado de folha de um nó do Cassandra ou aplicativo cliente é trivial.
  2. A rotação de um certificado intermediário ou raiz ainda é uma operação bastante complexa, mas a frequência dessas rotações será muito menor do que a dos certificados de folha.

Use as práticas de segurança da sua organização para decidir se vai usar certificados raiz e intermediários comuns em diferentes clusters de nuvem privada. Consulte Apêndice 2 para configurações alternativas de certificado.

As etapas restantes neste artigo fornecem detalhes sobre a metodologia acima de criação de chaves e certificados.

Limitações e ressalvas

As seguintes limitações se aplicam a esse recurso.

  • Essa oferta de mTLS nativo entre componentes do cliente e Cassandra NÃO é compatível com apigee-mtls. Se você estiver usando esse recurso, não poderá usar o apigee-mtls e vice-versa.
  • A ativação do mTLS entre os componentes do cliente e o Cassandra terá algum impacto no desempenho das conexões estabelecidas entre os clientes e o Cassandra. Operações como a inicialização de clientes ou o escalonamento de conexões do Cassandra podem ser mais lentas, já que o Cassandra e os clientes precisam negociar o TLS primeiro antes de iniciar a comunicação. O impacto precisa ser pequeno e geralmente não perceptível.
  • No Cassandra, o mTLS pode ser aplicado opcionalmente em conexões de cliente de entrada. Embora a aplicação possa ser ativada, ela precisa ser desativada durante tarefas operacionais, como upgrades do software da Apigee, ativação/desativação de recursos TLS e determinados tipos de rotações de certificados. Consulte a seção Operações e configurações para mais detalhes.
  • O gerenciamento e a manutenção de certificados são de responsabilidade do cliente.
  • A rotação de certificados tem várias nuances. Consulte a seção Rotações de certificados para mais detalhes.

Ativar o mTLS nativo

Em um nível alto, a ativação do mTLS nativo é um procedimento de três etapas, conforme descrito abaixo:

  1. Adquira um certificado raiz e um par de chave/certificado intermediário.
  2. Crie um par de chave/certificado de folha de um nó do Cassandra, assine-o, armazene-o em um keystore e configure o Cassandra para mTLS opcional. Repita as etapas para cada nó do Cassandra, um de cada vez.
  3. Crie um par de chave/certificado de folha de um aplicativo cliente, assine-o, armazene-o em um keystore e configure o aplicativo cliente para mTLS. Repita as etapas em cada aplicativo cliente, um de cada vez. Aplicativos cliente:
    1. edge-management-server
    2. edge-message-processor
    3. edge-router

Essas etapas são detalhadas abaixo:

Adquirir certificados raiz e intermediários

Adquira um certificado raiz e um par de chave/certificado intermediário assinado pela raiz. Use o certificado raiz e intermediário assinado pela AC da sua organização ou crie certificados autoassinados. Armazene a cadeia de certificados raiz e intermediários em um truststore. Consulte Apêndice 1 para comandos úteis. Os comandos subsequentes pressupõem que você tenha acesso aos seguintes arquivos:

  • intermediate.key - arquivo de chave para certificado intermediário para assinatura de certificados de folha
  • intermediate-cert.pem- certificado intermediário

Configurar nós do Cassandra

  1. Escolha um nó do Cassandra
  2. Gere um par de chave e certificado de folha e assine-o com o certificado intermediário. Armazene a chave e o certificado assinado em um keystore. Veja um exemplo a seguir:
    
    # Generate Leaf key and csr
    openssl req -newkey rsa:2048 -keyout cass-node1.key -out cass-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=cassnode1@yourorg.com"
    
    # leaf cert signed by intermediate
    openssl x509 -req -in cass-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out cass-node1-cert.pem
    
    # keystore packaging leaf key and cert
    openssl pkcs12 -export -clcerts -in cass-node1-cert.pem -inkey cass-node1.key -out cass-node1-keystore.pfx -name nativemtls -password pass:keystorepass

    Coloque os arquivos de keystore e truststore em um local específico no nó e verifique se eles estão acessíveis ao usuário da Apigee

    cp cass-node1-keystore.pfx /opt/apigee/customer/application/
    cp truststore.pfx /opt/apigee/customer/application/
    
    chown apigee:apigee /opt/apigee/customer/application/cass-node1-keystore.pfx
    chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties. Adicione o seguinte conteúdo a esse arquivo:
    ### Enable Cassandra TLS on CQL connections
    conf_cassandra_client_encryption_enabled=true
    
    ### Optional TLS - true or false
    conf_cassandra_client_encryption_optional=true
    
    ### Keystore details
    conf_cassandra_client_encryption_keystore=/opt/apigee/customer/application/cass-node1-keystore.pfx
    conf_cassandra_client_encryption_keystore_password=keystorepass
    conf_cassandra_server_encryption_store_type=PKCS12
    
    ### Whether to enable 2-way TLS (or mTLS) - true or false
    conf_cassandra_client_encryption_require_client_auth=true
    
    ### When 2-way TLS is enabled, client certificate details need to be provided via a truststore
    conf_cassandra_client_encryption_truststore=/opt/apigee/customer/application/truststore.pfx
    conf_cassandra_client_encryption_truststore_password=trustpass
    conf_cassandra_client_encryption_store_type=PKCS12
    

    Verifique se o arquivo pertence ao usuário da Apigee e pode ser lido por ele:

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Configure e reinicie o nó do Cassandra
    apigee-service apigee-cassandra configure
    apigee-service apigee-cassandra restart
    
  5. Repita as etapas acima em cada nó do Cassandra, um de cada vez

Configurar aplicativos cliente

Esta seção se aplica aos seguintes componentes do cliente que se conectam ao Cassandra:

  • edge-management-server
  • edge-message-processor
  • edge-router

  1. Escolha um componente do cliente
  2. Gere um par de chave e certificado de folha e assine-o com o certificado intermediário. Armazene a chave e o certificado assinado em um keystore. Veja um exemplo a seguir:
    
    # Generate Leaf key and csr
    openssl req -newkey rsa:2048 -keyout mgmt-node1.key -out mgmt-node1-req.pem -sha256 -days 365 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=yourip/emailAddress=mgmtnode1@yourorg.com"
    
    # leaf cert signed by intermediate
    openssl x509 -req -in mgmt-node1-req.pem -CAkey intermediate.key -CA intermediate-cert.pem -days 365 -CAcreateserial -out mgmt-node1-cert.pem
    
    # keystore packaging leaf key and cert
    openssl pkcs12 -export -clcerts -in mgmt-node1-cert.pem -inkey mgmt-node1.key -out mgmt-node1-keystore.pfx -name nativemtls -password pass:keystorepass
    

    Coloque os arquivos de keystore e truststore em um local específico no nó e verifique se eles estão acessíveis ao usuário da Apigee

    cp mgmt-node1-keystore.pfx /opt/apigee/customer/application/
    cp truststore.pfx /opt/apigee/customer/application/
    
    chown apigee:apigee /opt/apigee/customer/application/mgmt-node1-keystore.pfx
    chown apigee:apigee /opt/apigee/customer/application/truststore.pfx

  3. Crie e edite o arquivo de configuração com base no aplicativo que você está configurando
    Aplicativo Arquivo de configuração
    Servidor de gerenciamento /opt/apigee/customer/application/management-server.properties
    Processador de gerenciamento /opt/apigee/customer/application/message-processor.properties
    Roteador /opt/apigee/customer/application/router.properties

    Adicione as seguintes configurações ao arquivo:

    ### Enable TLS on CQL connections
    conf_cassandra_sslconfig.enable.tls=true
    conf_cassandra_sslconfig.enable.mtls=true
    
    ### Keystore Details
    conf_cassandra_sslconfig.keystore.path=/opt/apigee/customer/application/mgmt-node1-keystore.pfx
    conf_cassandra_sslconfig.keystore.password=keystorepass
    conf_cassandra_sslconfig.keystore.type=PKCS12
    
    ### Truststore Details
    conf_cassandra_sslconfig.truststore.path=/opt/apigee/customer/application/truststore.pfx
    conf_cassandra_sslconfig.truststore.password=trustpass
    conf_cassandra_sslconfig.truststore.type=PKCS12
    

    Verifique se o arquivo de configuração pertence ao usuário da Apigee e pode ser lido por ele

    chown apigee:apigee configuration file
    
    ### Example:
    chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    

  4. Reinicie o aplicativo cliente
    # Configure and restart service:
    apigee-service component configure
    apigee-service component restart
    # Example, to configure and restart message processor application
    apigee-service edge-message-processor configure
    apigee-service edge-message-processor restart
    
  5. É possível validar se o SSL foi configurado corretamente no aplicativo cliente procurando registros nas linhas abaixo no registro do sistema do aplicativo apropriado:

    Opções de SSL adicionadas à conexão do Cassandra

  6. Repita as etapas acima em cada aplicativo cliente, um de cada vez

Operações e configurações

Aplicar mTLS

Quando o mTLS não é aplicado no Cassandra, o Cassandra aceita conexões de texto simples de clientes ou clientes com os quais ele pode realizar um handshake de TLS bidirecional. Para que a aplicação do mTLS funcione, o mTLS precisa ser configurado primeiro no Cassandra. É possível definir a aplicação do mTLS no Cassandra seguindo as etapas abaixo:

  1. Escolha um nó do Cassandra
  2. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties. Adicione ou edite a seguinte propriedade nesse arquivo:
    ### Optional TLS - true or false
    conf_cassandra_client_encryption_optional=false
    

    Verifique se o arquivo pertence ao usuário da Apigee e pode ser lido por ele

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    
  3. Configure e reinicie o nó do Cassandra
    apigee-service apigee-cassandra configure
    apigee-service apigee-cassandra restart
    
  4. Repita as etapas acima em cada nó do Cassandra, um de cada vez

Depois que o mTLS for aplicado no Cassandra, a ferramenta de consulta padrão do Cassandra, cqlsh, não poderá se conectar diretamente ao Cassandra. Para configurar o cqlsh para SSL, gere uma nova chave e certificado de folha (semelhante à chave e certificado de folha para aplicativos cliente) e faça o seguinte:

  1. Crie ou edite o arquivo $HOME/.cassandra/cqlshrc
  2. Adicione o seguinte conteúdo ao arquivo:
    [ssl]
    certfile = /home/admin-user/certs/inter-root.pem
    validate = false
    userkey = /home/admin-user/certs/cqlsh1.key
    usercert = /home/admin-user/certs/cqlsh1-cert.pem
    
    • certfile - arquivo de certificado que contém a cadeia de certificados raiz e intermediária
    • userkey - chave do cliente a ser usada pelo cqlsh. Essa precisa ser uma chave/certificado de folha que você pode gerar e assinar com o certificado intermediário.
    • usercert - certificado do cliente a ser usado pelo cqlsh. Essa precisa ser uma chave/certificado de folha que você pode gerar e assinar com o certificado intermediário.
  3. Execute o comando cqlsh como de costume, fornecendo o argumento --ssl. Por exemplo:
    $  /opt/apigee/apigee-cassandra/bin/cqlsh --ssl X.X.X.X
    Connected to Apigee at X.X.X.X:9042
    [cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5]
    Use HELP for help.
    cqlsh>
    

Desativar a aplicação do mTLS no Cassandra

Para desativar a aplicação do mTLS no Cassandra, siga as etapas abaixo:

  1. Escolha um nó do Cassandra
  2. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties. Adicione ou edite a seguinte propriedade nesse arquivo:
    ### Optional TLS - true or false
    conf_cassandra_client_encryption_optional=true
    

    Verifique se o arquivo pertence ao usuário da Apigee e pode ser lido por ele

    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    
  3. Configure e reinicie o nó do Cassandra
    apigee-service apigee-cassandra configure
    apigee-service apigee-cassandra restart
    
  4. Repita as etapas acima em cada nó do Cassandra, um de cada vez

Desativar o mTLS nativo

A desativação do mTLS nativo é um processo de várias etapas, semelhante à ativação do mTLS nativo. As etapas de alto nível são:

  1. Desative a aplicação do mTLS no Cassandra (se aplicado).
  2. Desative o mTLS em todos os nós dos seguintes aplicativos cliente, um por um:
    • edge-management-server
    • edge-message-processor
    • edge-router
    1. Crie e edite o arquivo de configuração com base no aplicativo que você está configurando:
      Aplicativo Arquivo de configuração
      Servidor de gerenciamento /opt/apigee/customer/application/management-server.properties
      Processador de gerenciamento /opt/apigee/customer/application/message-processor.properties
      Roteador /opt/apigee/customer/application/router.properties
    2. Adicione ou edite as seguintes propriedades no arquivo de configuração:
      ### TLS on CQL connections
      conf_cassandra_sslconfig.enable.tls=false
      conf_cassandra_sslconfig.enable.mtls=false
      
    3. Verifique se o arquivo de configuração pertence ao usuário da Apigee e pode ser lido por ele:
      chown apigee:apigee configuration file
      
      ### Example:
      chown apigee:apigee /opt/apigee/customer/application/management-server.properties
    4. Reinicie o aplicativo cliente:
      
      # Configure and restart service:
      apigee-service component configure
      apigee-service component restart
      
      # Example, to configure and restart message processor application
      apigee-service edge-message-processor configure
      apigee-service edge-message-processor restart
      
    5. Repita as etapas de "a" a "d" em cada aplicativo cliente, um de cada vez.
  3. Desative o mTLS em todos os nós do Cassandra, um por um:
    1. Escolha um nó do Cassandra.
    2. Crie ou edite o arquivo /opt/apigee/customer/application/cassandra.properties. Adicione ou edite a seguinte propriedade nesse arquivo:
      ### Cassandra TLS on CQL connections
      conf_cassandra_client_encryption_enabled=false
      

      Verifique se o arquivo pertence ao usuário da Apigee e pode ser lido por ele

      chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
      
    3. Configure e reinicie o nó do Cassandra
    4. apigee-service apigee-cassandra configure
      apigee-service apigee-cassandra restart
      
    5. Repita as etapas de "a" a "c" em cada nó do Cassandra, um de cada vez.

Rotações de certificados

Rotação apenas para certificados de folha (mantendo os mesmos certificados raiz e intermediários)

Etapas semelhantes a Configurar aplicativos cliente podem ser seguidas:

  1. Gere uma nova chave/certificado de folha para um aplicativo usando a mesma chave/certificado intermediário.
  2. Configure o caminho para a nova chave/certificado de folha no aplicativo, juntamente com a senha e o tipo de keystore.
  3. Reinicie o aplicativo.
Rotação para certificados raiz ou intermediários

Se você planeja girar o certificado intermediário ou raiz, recomendamos fazer isso como um processo de várias etapas:

  1. Desative o mTLS nativo do Cassandra no cluster.
  2. Use os novos certificados raiz e intermediários para gerar novos certificados de folha ou de aplicativo.
  3. Siga as etapas para ativar o mTLS nativo do Cassandra usando o novo conjunto de chaves e certificados.

Operações gerais da Apigee

Para realizar operações gerais da Apigee, como upgrade do software da Apigee, adição ou remoção de nós do Cassandra, adição ou remoção de data centers, ativação ou desativação da autenticação do Cassandra etc., verifique se o mTLS não está aplicado no Cassandra. Se você tiver aplicado o mTLS, desative a aplicação antes de continuar com essas operações.

Apêndice 1

As etapas neste apêndice podem ser seguidas para gerar um par de chave/certificado raiz e intermediário autoassinado e adicionar essa cadeia de certificados a um truststore.

Gerar certificados raiz e intermediários autoassinados

# Create self-signed root key and cert
openssl req -x509 -newkey rsa:2048 -keyout root.key -out root-cert.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=root.yourorg.com/emailAddress=apigeeroot@yourorg.com"

# Create intermediate key and cert (signed by root)
openssl req -newkey rsa:2048 -keyout intermediate.key -out intermediate-req.pem -sha256 -days 3650 -nodes -subj "/C=yourc/ST=yourst/L=yourl/O=youro/OU=yourou/CN=inter.yourorg.com/emailAddress=apigeeinter@yourorg.com"

openssl x509 -req -in intermediate-req.pem -CAkey root.key -CA root-cert.pem -days 3650 -CAcreateserial -out intermediate-cert.pem

Gerar truststore

# Merge root and intermediate cert into 1 file
cat intermediate-cert.pem > inter-root.pem
cat root-cert.pem >> inter-root.pem

# Create truststore to be used everywhere
keytool -keystore truststore.pfx -storetype PKCS12 -importcert -file inter-root.pem -keypass trustpass -storepass trustpass -alias nativemtls -noprompt

Apêndice 2: configurações alternativas de encadeamento de certificados

Embora este artigo recomende uma configuração específica de encadeamento de certificados que equilibra a segurança e a facilidade de operações, existem alternativas descritas abaixo. A maioria dos princípios gerais também se aplica a outras metodologias, como:

  1. Ter chaves e certificados de folha diretos para cada nó do Cassandra ou aplicativo cliente (sem certificados raiz ou intermediários de assinatura). Isso provavelmente tornará a rotação de certificados complexa.
  2. Ter vários conjuntos raiz e intermediários para diferentes casos de uso. Por exemplo, os nós do Cassandra têm um conjunto de certificados raiz/intermediário usando o qual todos os certificados de folha do Cassandra são assinados. Da mesma forma, todos os aplicativos cliente podem ter um conjunto raiz/intermediário separado para assinar certificados de folha de aplicativo. Essas configurações são viáveis, mas envolvem a adição da cadeia de certificados raiz/intermediária ao truststore apropriado. Neste exemplo, os truststores do Cassandra precisam conter certificados raiz/intermediários do cliente, e os aplicativos cliente precisam ter a cadeia raiz/intermediária de nós do Cassandra no truststore.
  3. Semelhante ao acima, você pode ter vários conjuntos de certificados raiz e intermediários para diferentes regiões , mas todos os clientes e servidores em todas as regiões precisam estar cientes de todas as cadeias raiz e intermediárias, adicionando todas elas ao truststore configurado.