Gerenciando Conectores de Saída

O Armazenamento de Arquivos usa conectores de saída para se comunicar com um servidor externo, como um servidor LDAP.

Um conector de saída contém todas as informações necessárias para conectar, autenticar e obter autorização para executar as funções necessárias da conta. Atualmente, os conectores de saída são usados apenas para comunicação com servidores LDAP. Especifique as opções de configuração do conector ao adicionar autenticação LDAP a um ponto de acesso NFS.

Ao estabelecer conexão com um servidor LDAP, um ponto de acesso NFS usa o primeiro conector de saída especificado em sua configuração. Se o ponto de acesso NFS não fizer log-in no servidor LDAP usando o primeiro conector de saída, ele usará o segundo conector de saída.

Vários pontos de acesso NFS podem usar o mesmo conector de saída. Você só poderá associar um conector de saída a um ponto de acesso NFS quando eles existirem no mesmo domínio de disponibilidade. Você pode ter até 32 conectores de saída por domínio de disponibilidade.

Consulte os seguintes tópicos para obter instruções detalhadas relacionadas ao gerenciamento do conector de saída:

Política do Serviço IAM Necessária

Para usar o Oracle Cloud Infrastructure, um administrador deve ser membro de um grupo ao qual foi concedido acesso de segurança em uma política por um administrador da tenancy. Esse acesso será necessário se você estiver usando a Console ou a API REST com um SDK, uma CLI ou outra ferramenta. Se você receber uma mensagem informando que não tem permissão ou está não autorizado, verifique com o administrador da tenancy qual tipo de acesso você tem e qual compartimento seu acesso funciona.

Para administradores: A política em Permitir que os usuários criem, gerenciem e excluam sistemas de arquivos permite que os usuários gerenciem conectores de saída.

Como os conectores de saída também exigem acesso a segredos para estabelecer conexão com um servidor externo, como um servidor LDAP, são necessárias políticas adicionais do IAM para o usuário que configura o ponto de acesso NFS e o próprio ponto de acesso NFS.

Importante

Essas políticas devem ser criadas para que você possa configurar pontos de acesso NFS para usar o LDAP para autorização.

Política para Ativar a Configuração do Ponto de Acesso NFS

Conceda ao usuário ou grupo a configuração do LDAP em permissões de um ponto de acesso NFS usando uma política como a seguinte. Isso permite que o usuário leia os segredos do Vault necessários durante a configuração.

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID>, target.secret.id = <Trusted_Certificate_Secret_ID> }

Isso permite que o usuário emita comandos do File Storage que lerão os segredos do Vault e exibirão partes do segredo para validação durante a configuração.

Política para Permitir que um Ponto de Acesso NFS Recupere Segredos

O serviço File Storage requer a capacidade de ler os segredos. O File Storage usa controladores de recursos para conceder a um conjunto específico de pontos de acesso NFS acesso ao segredo do Vault. Este é um processo de duas etapas, primeiro os pontos de acesso NFS que precisam de acesso devem ser colocados em um grupo dinâmico e, em seguida, o grupo dinâmico recebe acesso para ler os segredos.

Crie um grupo dinâmico para os pontos de acesso NFS com uma política como a seguinte:
```
ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
```
Observação

Se você tiver mais de uma regra em um grupo dinâmico, certifique-se de usar a opção Match any rules defined below.

Crie uma política do serviço IAM que dê ao grupo dinâmico de pontos de acesso NFS acesso de leitura aos segredos do Vault:

 allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>

Se você não conhece as políticas, consulte Conceitos Básicos de Políticas e Detalhes do Serviço File Storage.

Detalhes sobre um Conector de Saída

A página de detalhes fornece as seguintes informações sobre um conector de saída:

OCID: Cada recurso do Oracle Cloud Infrastructure tem um ID exclusivo designado pela Oracle chamado OCID (Oracle Cloud Identifier). Você precisa do OCID de um conector de saída para usar a Interface da Linha de Comando (CLI) ou a API. Você também precisa do OCID ao entrar em contato com o suporte. Consulte Identificadores de Recursos.
CRIADO EM: A data e a hora em que o conector de saída foi criado.
COMPARTIMENTO: Ao criar um conector de saída, você especifica o compartimento em que ele reside. Um compartimento é um conjunto de recursos relacionados (como redes na nuvem, instâncias de computação ou sistemas de arquivos) que só podem ser acessados por esses grupos que receberam permissão de um administrador em sua organização. Você precisa do compartimento do seu conector de saída para usar a Interface da Linha de Comando (CLI) ou a API. Para obter mais informações, consulte Gerenciando Compartimentos.
DOMÍNIO DE DISPONIBILIDADE: Ao criar um conector de saída, você especifica o domínio de disponibilidade em que ele reside. Um domínio de disponibilidade é um ou mais data centers em uma região. Você precisa do domínio de disponibilidade de um conector de saída para usar a CLI ou a API. Para obter mais informações, consulte Regiões e Domínios de Disponibilidade.
TIPO DE CONECTOR: O tipo de conector de saída. O único tipo suportado é LDAPBIND.
NOME DO DNS DO SERVIDOR: O nome do domínio totalmente qualificado da instância em que o serviço LDAP está em execução.
PORT: a porta LDAPS do serviço LDAP.
NOME EXCLUSIVO DO BIND: O Nome Distinto LDAP usado para fazer log-in no servidor LDAP.
OCID DO SEGREDO: O OCID do segredo no Vault que contém a senha associada ao Nome Distinto do Bind.
VERSÃO DO SEGREDO: O número da versão do segredo da senha LDAP.
ATIVAR CERTIFICADO CONFIÁVEL: Indica se o conector de saída está configurado para usar um certificado confiável para conexões LDAPS.
SEGREDO DO CERTIFICADO CONFIÁVEL: O OCID do segredo no Vault que contém o certificado confiável.
VERSÃO DO SEGREDO DO CERTIFICADO CONFIÁVEL: O número da versão do segredo do certificado confiável.

Diagnosticando e Solucionando Erros de Solicitação Inválida (HTTP 400) ao Configurar um Certificado Confiável

Se você criar um conector de saída e tiver fornecido um OCID de segredo de Certificado Confiável e uma versão de segredo, a solicitação poderá falhar com Solicitação Inválida (HTTP 400). Isso geralmente significa que o serviço não pôde validar o segredo, a versão ou o conteúdo do certificado.

Aqui estão algumas causas e correções comuns:

Causa: OCID do segredo do Vault inválido

O OCID do Certificado Confiável informado não é um OCID Secret do serviço Vault (ou o nome do segredo é inválido).

Solução: Usar um OCID de segredo do Vault válido

Confirme os pontos do OCID para um Segredo do Vault (não um vault, uma chave ou outro tipo de recurso).
Atualize o conector de saída para usar o OCID correto do segredo do certificado confiável.

Causa: versão do segredo inválida

A versão do segredo do certificado confiável deve ser maior que 0. Se você usar 0 (ou um número negativo), a validação falhará.

Solução: Defina a versão para um número maior que 0

No Vault, verifique as versões de segredo disponíveis para seu segredo de certificado confiável.
Atualize o conector de saída para usar uma versão de segredo maior que 0.

Causa: certificado raiz autoassinado ausente

O serviço lê o certificado (ou pacote) do segredo e espera encontrar um certificado (raiz) autoassinado. Se não conseguir encontrar um, a validação falhará.

Solução: Certifique-se de que o segredo inclua um certificado raiz autoassinado

Verifique o conteúdo do segredo e confirme se ele inclui um certificado de CA raiz autoassinado (como um único certificado ou em um bundle).
Atualize o conteúdo do segredo do Vault, se necessário, e crie novamente o conector de saída.

Causa: Certificado raiz expirado

O certificado (raiz) autoassinado encontrado no segredo está com a validade vencida. Você pode ver a mensagem Root Certificate is expired.

Solução: Substitua o certificado expirado

Faça upload de um certificado raiz válido (não expirado) no segredo do Vault.
Se a atualização criar uma nova versão de segredo, atualize o conector de saída para usar essa versão e tente novamente.

Causa: falha no acesso ao segredo do Vault

O serviço não pode ler o segredo (por exemplo, por causa de permissões ausentes, indisponibilidade do segredo ou problemas de conectividade).

Remédio: Confirmar permissões e acesso ao segredo

Verifique se as políticas do serviço IAM permitem que o usuário que está fazendo a alteração e o ponto de acesso NFS (diretório de recursos) leia secret-family no compartimento do segredo.
Confirme se o segredo existe e está disponível e se o acesso ao Vault está funcionando no seu ambiente.

Causa: formato de certificado X.509 inválido

O conteúdo do segredo não é um certificado X.509 válido (ou pacote de certificados); portanto, o serviço não pode fazer parsing dele.

Solução: Armazene um certificado (ou pacote) X.509 válido

Confirme se os dados do certificado armazenados são um certificado X.509 (ou bundle) formatado corretamente e não estão truncados ou corrompidos.
Atualize o segredo do Vault com o conteúdo do certificado corrigido e repita a criação/atualização do conector de saída.

Documentação do Oracle Cloud Infrastructure