Este tópico explica como configurar a autenticação para a comunicação entre os nós do Cassandra e entre os clientes e os nós do Cassandra.
Como configurar a autenticação para o Cassandra no plano de tempo de execução
O Cassandra oferece uma comunicação segura entre uma máquina cliente e um cluster de base de dados, bem como entre nós num cluster. A ativação da encriptação garante que os dados em trânsito não são comprometidos e são transferidos de forma segura. No Apigee hybrid, o TLS está ativado por predefinição para qualquer comunicação entre nós do Cassandra e entre clientes e nós do Cassandra.
Pode configurar a autenticação através de combinações de nome de utilizador/palavra-passe colocadas diretamente no ficheiro de substituições ou adicionadas a um segredo do Kubernetes, conforme explicado neste tópico.
Acerca da autenticação de utilizadores do Cassandra
A plataforma híbrida usa o Cassandra como o armazenamento de dados de back-end para dados do plano de tempo de execução. Por predefinição, qualquer comunicação do cliente com o Cassandra requer autenticação. Existem vários utilizadores clientes que comunicam com o Cassandra. São fornecidas palavras-passe predefinidas para estes utilizadores. Consulte a secção Alterar as palavras-passe predefinidas no ficheiro de substituições para ver os passos necessários para alterar as palavras-passe predefinidas.
Estes utilizadores, incluindo um utilizador predefinido, estão descritos abaixo:
- Utilizador DML: usado pelo cliente para ler e escrever dados no Cassandra (KMS, KVM, cache e quota).
- Utilizador DDL: usado pelo MART para qualquer uma das tarefas de definição de dados, como a criação, a atualização e a eliminação de keyspaces.
- Utilizador administrador: usado para quaisquer atividades administrativas realizadas no cluster do Cassandra.
- Utilizador predefinido do Cassandra: o Cassandra cria um utilizador predefinido quando
a autenticação está ativada e o nome de utilizador é
cassandra - Utilizador JMX: usado para autenticar e comunicar com a interface JMX do Cassandra.
- Utilizador do Jolokia: usado para autenticar e comunicar com a API JMX do Cassandra.
Acerca do utilizador predefinido do Cassandra
Quando o cluster híbrido do Apigee é criado e a autenticação do Cassandra está ativada, a conta de utilizador inicial é o utilizador predefinido do Cassandra, identificado pelo nome de utilizador cassandra. As funções de utilizador cassandra predefinidas atuam como superutilizadores, responsáveis por tarefas como adicionar funções de utilizador e modificar o esquema da base de dados.
A tarefa apigee-cassandra-user-setup do Apigee hybrid usa o utilizador cassandra predefinido para estabelecer novas funções e atualizar a palavra-passe associada a este utilizador predefinido. A execução da tarefa apigee-cassandra-user-setup ocorre durante a instalação inicial de uma instância híbrida do Apigee, as atualizações subsequentes da instância e o aprovisionamento de uma nova instância como parte da expansão da região.
Quando a tarefa do Apigee hybrid apigee-cassandra-user-setup é executada, precisa de poder atualizar e modificar as configurações ao nível da base de dados como parte de uma nova instalação ou de uma atualização. O utilizador cassandra predefinido é o único utilizador cuja presença é garantida quando a tarefa apigee-cassandra-user-setup está a configurar os novos pods do Cassandra. Sem um utilizador conhecido com acesso de superutilizador, as atualizações e as expansões de regiões do Apigee hybrid não funcionariam corretamente.
A palavra-passe de utilizador cassandra predefinida é alterada após a utilização inicial como parte de medidas de segurança adicionais. Isto significa que, mesmo que o utilizador cassandra predefinido ainda esteja ativado, tem de saber a nova palavra-passe para usar o utilizador cassandra predefinido. O utilizador cassandra predefinido não é usado por nenhum outro componente, exceto a tarefa apigee-cassandra-user-setup, como parte da nova instalação e expansão da região.
Alterar as palavras-passe predefinidas no ficheiro de substituições
Como prática recomendada de segurança, recomendamos que altere as palavras-passe predefinidas do Cassandra. Pode fazê-lo no ficheiro overrides.yaml. Adicione a seguinte configuração, altere as palavras-passe predefinidas como quiser e aplique a alteração ao cluster. Consulte
cassandra. Pode ver as palavras-passe predefinidas no ficheiro 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
Tenha em conta o seguinte:
- A rotação da autoridade de certificação (AC) não é suportada.
- Não é suportado um certificado de servidor gerado com uma frase secreta.
Definir nomes de utilizador e palavras-passe num secret do Kubernetes
Esta secção explica como configurar o Cassandra para usar segredos do Kubernetes para autenticação.
Crie o Secret
Use o seguinte modelo para configurar o segredo do Kubernetes. Guarde o modelo num ficheiro YAML e edite os atributos obrigatórios, por exemplo, my-secret.yaml.
Tenha em atenção que, se usar esta opção, tem de indicar os nomes de utilizador com cada palavra-passe.
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
Onde SECRET_NAME é o nome que escolhe para o segredo, APIGEE_NAMESPACE
é o espaço de nomes onde os pods do Apigee são implementados (o predefinido é apigee) e, para cada utilizador, _USERNAME e _PASSWORD são os nomes de utilizador e as palavras-passe. Tenha em atenção que o nome de utilizador e a palavra-passe têm de estar codificados em Base64.
Aplique o segredo ao cluster. Por exemplo:
kubectl apply -f SECRET_FILE
Adicione o segredo ao ficheiro de substituições:
cassandra: auth: secret: SECRET_NAME
Aplique a substituição do Cassandra atualizada ao cluster:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Verifique os registos do Cassandra
Verifique os registos assim que o Cassandra for iniciado. O registo abaixo mostra que as ligações do cliente Cassandra estão encriptadas.
kubectl logs apigee-cassandra-2 -n APIGEE_NAMESPACE -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...