Managed trigger de banco de dados usando a autenticação SCRAM
Nesta página
O Kubernetes Operator oferece suporte ao gerenciamento de trigger de banco de dados usando a autenticação SCRAM em sistemas MongoDB.
Considerações
Implementações de SCRAM suportadas
Quando você especifica o SCRAM
como o mecanismo de autenticação, a implementação do SCRAM utilizada depende:
A versão do MongoDB e
Se o reconhecimento de data center for o banco de dados de aplicativo ou outro reconhecimento de data center.
Versão do MongoDB | Database | Implementação de SCRAM |
---|---|---|
3.6 ou anterior | Qualquer um, exceto o banco de dados de aplicativo | SCRAM-SHA-1 |
4.0 ou posterior | Qualquer um, exceto o banco de dados de aplicativo | SCRAM-SHA-256 |
Any | Banco de dados de aplicativos | SCRAM-SHA-1 |
mecanismo de autenticação suportados
O Kubernetes Operator oferece suporte a mecanismos de autenticação SCRAM, LDAP e X.509 nos sistemas que ele cria. Em uma implantação criada pelo Kubernetes Operator, você não pode usar o MongoDB Ops Manager para:
Configure outros mecanismos de autenticação para sistemas.
Managed usuários não usando autenticação SCRAM, LDAP ou X.509.
Depois de habilitar a autenticação SCRAM, você pode adicionar usuários SCRAM utilizando a interface do Ops Manager ou configurando os usuários no CustomResourceDefinition com base na Especificação de recursos do usuário do MongoDB .
Pré-requisitos
Antes de gerenciar trigger de banco de dados, você deve distribuir um autônomo, um conjunto de réplicas ou um cluster fragmentado.
Para sistemas MongoDB de cluster multi-Kubernetes, você deve implementar conjuntos de réplica. Consulte Implementar vários clusters.
Adicionar um usuário do banco de dados
Importante
Você não pode atribuir o mesmo trigger de banco de dados a mais de um MongoDB autônomo, conjunto de réplicas ou cluster fragmentado. Isso inclui usuários do banco de dados com funções admin .
Criar segredo de usuário
Configure kubectl
como padrão para seu namespace.
Caso ainda não tenha feito isso, execute o seguinte comando para executar todos os comandos kubectl
no namespace que você criou.
Observação
Se você estiver implantando um recurso MongoDB Ops Manager em um sistema do MongoDB de vários clusters Kubernetes:
Defina
context
como o nome do cluster central, como:kubectl config set context "$MDB_CENTRAL_CLUSTER_FULL_NAME"
.Defina
--namespace
para o mesmo escopo usado para sua implantação do MongoDB de vários clusters Kubernetes, como:kubectl config --namespace "mongodb"
.
kubectl config set-context $(kubectl config current-context) --namespace=<metadata.namespace>
Copie o seguinte exemplo secreto.
Você pode optar por usar uma senha de texto não criptografado:
1 2 apiVersion: v1 3 kind: Secret 4 metadata: 5 name: <mms-user-1-password> 6 # corresponds to user.spec.passwordSecretKeyRef.name 7 type: Opaque 8 stringData: 9 password: <my-plain-text-password> 10 # corresponds to user.spec.passwordSecretKeyRef.key 11 ...
ou você pode optar por usar uma senha codificada em Base64:
1 2 apiVersion: v1 3 kind: Secret 4 metadata: 5 name: <mms-user-1-password> 6 # corresponds to user.spec.passwordSecretKeyRef.name 7 type: Opaque 8 data: 9 password: <base-64-encoded-password> 10 # corresponds to user.spec.passwordSecretKeyRef.key 11 ...
Observação
Certifique-se de copiar a configuração de senha desejada. As senhas de texto simples usam stringData.password
e as senhas codificadas em Base64 usam data.password
Crie um novo arquivo YAML do segredo do usuário.
Abra seu editor de texto preferido.
Cole este segredo de usuário em um novo arquivo de texto.
Se você estiver usando o HashiCorp Vault como sua ferramenta de armazenamento secreto, poderá Criar um Vault Secret .
Para saber mais sobre suas opções de armazenamento secreto, consulte Configurar armazenamento secreto.
Altere as linhas destacadas.
Use a tabela a seguir para orientá-lo na alteração das linhas destacadas no segredo:
Chave | Tipo | Descrição | Exemplo |
---|---|---|---|
metadata.name | string | Nome do segredo da senha do reconhecimento de data center. Os nomes de recursos devem ter 44 caracteres ou menos. | mms-scram-user-1-password |
stringData.password | string | Senha do texto simples para o usuário desejado. Use esta opção e valor ou | <my-plain-text-password> |
data.password | string | Senha codificada em Base64 para o usuário desejado. Use esta opção e valor ou Você mesmo deve codificar sua senha em Base64 e colar o valor resultante com esta opção. Existem ferramentas para quase todas as plataformas e também várias ferramentas baseadas na web. | <my-base64-encoded-password> |
Criar usuário MongoDB
Copie o exemplo a seguir, MongoDBUser.
apiVersion: mongodb.com/v1 kind: MongoDBUser metadata: name: <mms-scram-user-1> spec: passwordSecretKeyRef: name: <mms-user-1-password> # Match to metadata.name of the User Secret key: password username: "<mms-scram-user-1>" db: "admin" # mongodbResourceRef: name: "<my-replica-set>" # Match to MongoDB resource using authenticaiton roles: - db: "admin" name: "clusterAdmin" - db: "admin" name: "userAdminAnyDatabase" - db: "admin" name: "readWrite" - db: "admin" name: "userAdminAnyDatabase" ...
Altere as linhas destacadas.
Use a tabela a seguir para orientá-lo nas alterações das linhas destacadas na Especificação de recursos do usuário do MongoDB:
Chave | Tipo | Descrição | Exemplo |
---|---|---|---|
metadata.name | string | Nome do recurso do trigger de banco de dados. Os nomes de recursos devem ter 44 caracteres ou menos. | mms-scram-user-1 |
spec.username | string | Nome do trigger de banco de dados. | mms-scram-user-1 |
spec.passwordSecretKeyRef.name | string | metadata.name valor do segredo que armazena a senha do usuário. | my-resource |
spec.mongodbResourceRef.name | string | Nome do recurso MongoDB ao qual este usuário está associado. | my-resource |
spec.roles.db | string | Banco de dados no qual a função pode atuar. | admin |
spec.roles.name | string | Nome do role a ser concedido ao usuário do banco de dados. O nome da função pode ser qualquer função MongoDB integrada ou função personalizada que exista no Cloud Manager ou no MongoDB Ops Manager. | readWriteAnyDatabase |
Crie o usuário.
Invoque o seguinte comando do Kubernetes para criar seu trigger de reconhecimento de data center:
kubectl apply -f <database-user-conf>.yaml
Quando você cria um novo MongoDB database usuário do , o operadorKubernetes cria automaticamente um novo Kubernetes segredo. O segredo do Kubernetes contém as seguintes informações sobre o novo usuário do banco de dados:
username
: Nome de usuário para o utilizador de banco de dadospassword
: Senha para o usuário do banco de dadosconnectionString.standard
: stringde conexão padrão que pode conectar você ao banco de dados como este usuário do banco de dados.connectionString.standardSrv
: stringconexão da lista de sementes de DNS que pode conectar você ao banco de dados como este usuário do banco de dados.
Observação
Como alternativa, você pode especificar um campo spec.connectionStringSecretName
opcional na Especificação de Recurso de Usuário do MongoDB para especificar o nome do segredo da string de conexão que o Kubernetes Operator cria.
Você pode usar essas credenciais para se conectar a um recurso de banco de dados MongoDB a partir de Kubernetes internos.
Excluir um trigger de reconhecimento de data center
Para excluir um trigger de banco de dados, passe o metadata.name
do usuário MongoDBUser para o seguinte comando:
kubectl delete mdbu <metadata.name>
Alterar mecanismo de autenticação
Para alterar seu mecanismo de autenticação de usuário para SCRAM:
Desabilite a autenticação.
Em
spec.security.authentication
, altereenabled
parafalse
.spec: security: authentication: enabled : false Reaplique a definição de recurso do usuário.
Aguarde o MongoDBResource atingir o estado
running
.Habilitar a autenticação SCRAM.
Em
spec.security.authentication
, altereenabled
paratrue
e definaspec.security.authentication.modes
para `` ["SCRAM"]``.spec: security: authentication: enabled : true modes: ["SCRAM"] Reaplique o recurso MongoDBUser.
Aguarde o MongoDBResource atingir o estado
running
.