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 a autenticação do 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á vários usuários clientes que se comunicam com o Cassandra. Senhas padrão são fornecidas para esses usuários. Consulte Como alterar as senhas padrão no arquivo de substituições para ver as etapas necessárias para alterar as senhas padrão.
Esses usuários, incluindo um usuário padrão, estão descritos abaixo:
- Usuário DML: usado pelo 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.
Sobre o usuário padrão do Cassandra
Quando o cluster da Apigee híbrida é criado e a autenticação do Cassandra é ativada, a conta de usuário inicial é o usuário padrão do Cassandra, identificado pelo nome de usuário cassandra. O usuário padrão cassandra funciona como um superusuário, responsável por tarefas como adicionar funções de usuário e modificar o esquema do banco de dados.
O job apigee-cassandra-user-setup da Apigee híbrida utiliza o usuário padrão cassandra para estabelecer novos papéis e atualizar a senha associada a ele. A execução do job apigee-cassandra-user-setup ocorre durante a instalação inicial de uma instância da Apigee híbrida, os upgrades subsequentes de instância e o provisionamento de uma nova instância como parte da expansão da região.
Quando o job apigee-cassandra-user-setup da Apigee híbrida é executado, ele precisa atualizar e modificar as configurações do banco de dados como parte de uma nova instalação ou de um upgrade. O usuário padrão cassandra é o único com presença garantida quando o job apigee-cassandra-user-setup estiver configurando os novos pods do Cassandra. Sem um usuário conhecido com acesso de superusuário, os upgrades da Apigee híbrida e as expansões das regiões não funcionariam corretamente.
A senha do usuário padrão cassandra muda após o uso inicial como parte de medidas extras de segurança. Isso significa que, mesmo que o usuário padrão cassandra ainda esteja ativado, é preciso conhecer a nova senha para usar o usuário padrão cassandra. O usuário padrão cassandra não é usado por nenhum outro componente, exceto o job apigee-cassandra-user-setup, como parte da nova instalação e expansão da região.
Como alterar as senhas padrão no arquivo de modificações
Como prática recomendada de segurança, mude as senhas padrão do Cassandra. Você pode fazer isso no arquivo overrides.yaml. Adicione a configuração a seguir, altere as senhas padrão como quiser e aplique a alteração ao
cluster. Consulte
cassandra. Você pode ver as senhas padrão
no arquivo values.yaml.
cassandra: auth: default: ## the password for the new default user (static username: cassandra) password: "NEW_PASSWORD" admin: ## the password for the admin user (static username: admin_user) password: "NEW_PASSWORD" ddl: ## the password for the DDL User (static username: ddl_user) password: "NEW_PASSWORD" dml: ## the password for the DML User (static username: dml_user) password: "NEW_PASSWORD" jmx: username: "jmxuser" ## the username for the JMX User password: "NEW_PASSWORD" ## the password for the JMX User jolokia: username: "jolokiauser" ## the username to access jolokia interface password: "NEW_PASSWORD" ## 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 YAML e edite os atributos necessários, por exemplo, my-secret.yaml.
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: DEFAULT_PASSWORD #base64-encoded string admin.user: ADMIN_USERNAME #base64-encoded string admin.password: ADMIN_PASSWORD #base64-encoded string dml.user: DML_USERNAME #base64-encoded string dml.password: DML_PASSWORD #base64-encoded string ddl.user: DDL_USERNAME #base64-encoded string ddl.password: DDL_PASSWORD #base64-encoded string jmx.user: JMX_USERNAME #base64-encoded string jmx.password: JMX_PASSWORD #base64-encoded string jolokia.user: JOLOKIA_USERNAME #base64-encoded string jolokia.password: JOLOKIA_PASSWORD #base64-encoded string
Em que SECRET_NAME é o nome escolhido para o secret, APIGEE_NAMESPACE é o namespace onde os pods da Apigee são implantados (o padrão é apigee) e cada _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. Por 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:
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
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...