Como configurar o TLS para o Cassandra

Você está visualizando a versão 1.7 da documentação da Apigee híbrida. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões compatíveis.

Version 1.7 (unsupported)

Versões com suporte:

• v1.12 (mais recente)
• v1.11
• v1.10
• Lista de versões com suporte

Versões sem suporte:

• v1.9
• v1.8                                         
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

Neste tópico, explicamos como configurar a autenticação para comunicação entre os nós do Cassandra e entre clientes e os nós do Cassandra.

Como configurar o TLS do Cassandra no plano de ambiente de execução

O Cassandra fornece comunicação segura entre uma máquina cliente e um cluster de banco de dados e entre nós dentro de um cluster. A ativação da criptografia garante que os dados em trânsito não sejam comprometidos e sejam transferidos com segurança. No híbrido da Apigee, o TLS é ativado por padrão para qualquer comunicação entre os nós do Cassandra e entre os clientes e os nós do Cassandra.

Configure a autenticação usando combinações de nome de usuário/senha colocadas diretamente no arquivo de modificações ou adicionadas a um secret do Kubernetes, conforme explicado neste tópico.

Sobre a autenticação de usuários do Cassandra

A plataforma híbrida usa o Cassandra como armazenamento de dados de back-end para dados do plano de ambiente de execução. Por padrão, qualquer comunicação do cliente com o Cassandra requer autenticação. Há três usuários utilizados pelos clientes que se comunicam com o Cassandra. As senhas padrão são fornecidas a esses usuários, e você não precisa alterá-las.

Esses usuários, incluindo um usuário padrão, estão descritos abaixo:

• Usuário DML: usado pela comunicação do cliente para ler e gravar dados no Cassandra (KMS, KVM, Cache e Quota).
• Usuário DDL: usado pelo MART para qualquer uma das tarefas de definição de dados, como criação, atualização e exclusão de espaço de chave.
• Usuário administrador: usado para qualquer atividade administrativa realizada em cluster cassandra.
• Usuário padrão do Cassandra: o Cassandra cria um usuário padrão quando a autenticação está ativada e o nome de usuário é cassandra.
• Usuário JMX: usado para autenticar e se comunicar com a interface do Cassandra JMX.
• Usuário do Jolokia: usado para autenticar e se comunicar com a API do Cassandra JMX.

Como alterar as senhas padrão no arquivo de modificações

O híbrido da Apigee fornece senhas padrão para os usuários do Cassandra. Se você quiser alterar as senhas de usuário padrão, faça isso no arquivo overrides.yaml. Adicione a configuração a seguir, altere as senhas padrão ("iloveapis123") como quiser e aplique a alteração ao seu cluster.

Observação: só é possível alterar esses padrões no momento da configuração inicial. A rotação ou alteração da senha após a configuração híbrida não é possível.

Todos os nomes de usuário precisam estar em letras minúsculas, e não são permitidos caracteres especiais.

cassandra:
   auth:
     default:  ## the password for the new default user (static username: cassandra)
       password: "iloveapis123"
     admin: ## the password for the admin user (static username: admin_user)
       password: "iloveapis123"
     ddl: ## the password for the DDL User (static username: ddl_user)
       password: "iloveapis123"
     dml: ## the password for the DML User (static username: dml_user)
       password: "iloveapis123"
     jmx:
       username: "jmxuser" ## the username for the JMX User
       password: "iloveapis123" ## the password for the JMX User
     jolokia:
       username: "jolokiauser" ## the username to access jolokia interface
       password: "iloveapis123" ## the password for jolokia user

Observe o seguinte:

• A rotação da autoridade de certificação (CA, na sigla em inglês) não é compatível.
• Um certificado de servidor gerado com a senha longa não é compatível.

Como definir nomes de usuário e senhas em um secret do Kubernetes

Nesta seção, explicamos como configurar o Cassandra para usar os secrets do Kubernetes na autenticação.

Criar o secret

Use o modelo a seguir para configurar o Kubernetes Secret. Salve o modelo em um arquivo e edite os atributos necessários. Observe que, se você usar essa opção, precisará fornecer os nomes de usuário com cada senha.

apiVersion: v1
kind: Secret
metadata:
  name: $SECRET_NAME
  namespace: $APIGEE_NAMESPACE
type: Opaque
data:
  default.password: $PASSWORD   #base64-encoded string
  admin.user: $USERNAME   #base64-encoded string
  admin.password: $PASSWORD   #base64-encoded string
  dml.user: $USERNAME   #base64-encoded string
  dml.password: $PASSWORD   #base64-encoded string
  ddl.user: $USERNAME   #base64-encoded string
  ddl.password: $PASSWORD   #base64-encoded string
  jmx.user: $USERNAME   #base64-encoded string
  jmx.password: $PASSWORD   #base64-encoded string
  jolokia.user: $USERNAME   #base64-encoded string
  jolokia.password: $PASSWORD   #base64-encoded string
  

Em que $SECRET_NAME é o nome escolhido para o secret, $APIGEE_NAMESPACE é o namespace em que os pods da Apigee são implantados (o padrão é apigee) e $USERNAME e $PASSWORD são os nomes de usuário e as senhas de cada usuário. Observe que o nome de usuário e a senha precisam ser codificados em Base64.

Aplique o secret ao cluster. Exemplo:

kubectl apply -f $SECRET_FILE

Adicione o secret ao seu arquivo de modificação:

cassandra:
  auth:
    secret: $SECRET_NAME

Aplique a modificação atualizada do Cassandra ao cluster:

$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml --datastore

Verificar os registros do Cassandra

Verifique os registros assim que o Cassandra for iniciado. O registro abaixo mostra que as conexões do cliente do Cassandra estão criptografadas.

kubectl logs apigee-cassandra-2 -n apigee -f

INFO  00:44:36 Starting listening for CQL clients on /10.0.2.12:9042 (encrypted)...
INFO  00:44:36 Binding thrift service to /10.0.2.12:9160
INFO  00:44:36 enabling encrypted thrift connections between client and server
INFO  00:44:36 Listening for thrift clients...