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.
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...