Pular para o conteúdo principal

Secrets

Visão Geral​

A maioria dos sistemas externos a serem integrados são protegidos por mecanismos de autenticação, como senhas, chaves privadas e tokens de autenticação. Por se tratarem de dados sensíveis, o DHuO possui um meio de armazenamento desses dados de maneira segura. Os secrets desempenham esse papel ao armazenar os dados confidenciais de autenticação criptografados em um cofre de segurança, chamado Vault. Por sua vez, esses secrets podem ser usados nos fluxos de integração em componentes que exijam autenticação para acesso.

O DHuO possui diferentes tipos de secrets, conforme os tipos de autenticação dos componentes. Os tipos disponíveis são:

  • Autenticação: para autenticação baseada em usuário e senha. Utilizado nos componentes: PostgreSQL, Oracle Database, Microsoft SQL Server, MySQL, MongoDB, RabbitMQ, MQTT, SMTP (Email), OPC UA, SAP ECC, SAP HANA, PI System e nos Triggers RabbitMQ e MQTT
  • Chaves de acesso: para autenticação baseada em access keys da AWS. Utilizado no componente Amazon S3.
  • Senha: para autenticação apenas com senha. Utilizado no componente Redis.
  • Service Account: para autenticação baseada em service Accounts do Google Cloud (GCP). Utilizado nos componentes Bigtable, Pub/Sub, Google Cloud Storage e Trigger Pub/Sub.
  • Token: para autenticação baseada em access tokens. Utilizado nos componentes Azure ADLS 2 e PI System.

Assim como as variáveis, os secrets podem ter valores distintos entre ambientes onde a integração é implantada.

Após criar um secret, ele está disponível para uso nos formulários de configuração de componentes durante a criação da integração no canvas.

Após a implantação da integração, todos os secrets associados a ela serão obtidos do cofre de segurança do DHuO (Vault) e disponibilizados como variáveis de ambiente, no formato base64, para o serviço no cluster.

Atenção!

As informações dos secrets só são utilizadas de fato no momento da implantação de integrações. Se uma ou mais integrações utilizam um secret cujo valor foi alterado, será necessário atualizar a implantação correspondente a cada uma delas para o novo valor ser replicado para os respectivos ambientes/clusters.

No entanto, não é necessário criar uma nova release da integração caso apenas valores de secrets tenham sido alterados. É necessário apenas a atualização da implantação. Para saber mais, acesse a seção Implantação (Deploy) de integrações.

Configuração​

Os secrets são gerenciados no contexto da Organização. A partir da home, acesse o ícone de configurações da Organização ⚙ menu > Secrets. Na página de secrets, eles podem ser cadastrados, editados e excluídos.

Permissões​

Apenas usuários com papel de administrador da organização (Org Admin) podem gerenciar secrets. Para saber mais, acesse a seção Papéis e permissões.

Parâmetros​

Aqui estão os parâmetros gerais para a configuração de um secret:

  • Nome: Obrigatório. Nome do secret.
Informação adicional

Os secrets são únicos por Organização. Não é possível ter mais de um secret com o mesmo nome.

O nome de um secret não pode conter espaços e pode conter apenas letras sem acentos, números e o caractere _.

  • Tipo de Secret: Obrigatório. Tipo do secret a ser armazenado no cofre de segurança. Opções: Autenticação, Chaves de acesso, Senha, Service Account, Token.
Atenção!

Não é possível alterar o nome e tipo do secret após a criação do secret. Caso seja necessário alterá-los, é preciso excluir o secret e criar um novo com as configurações desejadas.

Configurações por ambiente

Para cada ambiente onde o secret será utilizado, é necessário configurar:

  • Cluster: Obrigatório. Cluster que receberá o valor específico do secret durante a implantação de integrações que o utilizem. Para saber mais sobre clusters, acesse a seção Clusters da Administração do iPaaS.

Para o tipo Autenticação

  • Usuário: Obrigatório. Nome do usuário da autenticação.
  • Senha: Obrigatório. Senha de autenticação.

Para o tipo Chaves de acesso

  • Chave de acesso: Obrigatório. Identificador (Access Key ID).
  • Chave secreta: Obrigatório. Secret (Access Key).

Para o tipo Senha

  • Senha: Obrigatório. Senha de autenticação.

Para o tipo Service Account

  • Service Account: Obrigatório. Conteúdo da Service Account do GCP, no formato JSON.

Para o tipo Token

  • Token: Obrigatório. Token de autenticação.
Atenção!

Não é possível implantar uma integração que utiliza secrets sem que eles tenham valores declarados para o cluster onde ela será implantada.

Cuidado!

É possível excluir um secret mesmo que ele esteja em uso apenas nas configurações do canvas da integração.

Neste cenário, o secret será excluído, porém, não será possível implantar uma release da integração caso ela contenha o secret referenciado em algum componente no canvas.

Caso deseje implantar releases existentes com essa referência ao secret, será necessário recriar e configurar novamente o secret excluído. Caso contrário, será necessário excluir a referência do secret nos componentes do canvas e gerar uma nova release para implantação.