Como configurar a autenticação do Cassandra

Version 1.12 (latest)

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

1. Usuário DML: usado pelo cliente para ler e gravar dados no Cassandra (KMS, KVM, Cache e Quota).
2. 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.
3. Usuário administrador: usado para qualquer atividade administrativa realizada em cluster cassandra.
4. 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.
5. Usuário JMX: usado para autenticar e se comunicar com a interface do Cassandra JMX.
6. 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.

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

Observação: se você receber um erro dizendo Error: UPGRADE FAILED: "datastore" has no deployed releases, substitua upgrade por install e tente o comando novamente.

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