SSL para Certificados Assinados pela CA (Autoridade de Certificação)

Um certificado CA é criado, assinado e emitido por terceiros ou por uma autoridade de certificação (CA) autorizada a validar a identificação do assunto do certificado. Nos clusters do Big Data Service com a versão 3.0.7 e posterior, você pode executar a ferramenta de utilitário de certificado do Big Data Service para usar certificados SSL CA em seus clusters ODH.

Observação

  1. A Oracle gera um certificado de emissor e o adiciona ao armazenamento confiável nos nós do cluster.
  2. Os clusters ODH do Big Data Service suportam adição de nó sob demanda e dimensionamento automático. Para clusters ativados com certificados SSL assinados pela CA, durante a adição do nó, um certificado assinado pela Oracle é criado no novo nó para concluir o fluxo de adição do nó. Os nós recém-adicionados podem ser atualizados posteriormente com certificados assinados pela CA.
  3. A partir do Big Data Service versão 3.0.15, o ODH suporta a atualização de certificados assinados pela CA para nós de destino. Por exemplo, un0 e mn0. Nesses casos, você deve fornecer certificados para nós direcionados e todos os outros nós usam certificados assinados pela Oracle.
  4. Os clusters criados antes do Big Data Service versão 3.0.15 exigem certificados para todos os nós.

Ativando o SSL para Certificados Assinados pela Autoridade de Certificação (CA)

  1. Reunir os arquivos a seguir em uma pasta e compactá-la no formato .zip.
    • Certificado SSL assinado pela CA para cada nó ou nós direcionados (suportado no Big Data Service versão 3.0.15 ou posterior) no cluster ODH com base no FQDN do nó. Os certificados assinados pela CA devem estar no formato PEM (Privacy Enhanced Mail) com a extensão .crt.
    • A chave privada de cada certificado com a extensão .key.
    • Certificado raiz para o armazenamento confiável.
  2. Estabeleça SSH no primeiro nó principal (mn0) do nó do cluster ODH como usuário opc.
  3. Copie o arquivo zip para o primeiro nó principal (mn0).
    scp -i <node-key> <source/zip/filepath> opc@<mn0-public-ip>:<path/to/destination>

    Por exemplo:

    scp -i ssh_login.key /home/test/certificates.zip opc@192.168.0.10:/tmp/certificates.zip
  4. Descompacte o arquivo.
    unzip <filename>.zip -d </path/to/directory>

    Por exemplo:

    unzip certificates.zip -d /tmp/certs
  5. Edite /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf.
    vi /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf
    Por exemplo:
    # Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
    #
    [BDS_CERT_CONFIGS]
    #This files defines all the SSL certificate related configurations used in BDS cluster
    #Whether custom certificate or not
    CUSTOM_CERTIFICATE=false
    #Recommended SSL services, Mostly all the customer facing UI services
    #Allowed values AMBARI,RANGER,HUE,DATASTUDIO,LIVY
    DEFAULT_SSL_SERVICES=AMBARI
    #Comma separated service names for enabling SSL, These are the additional components from ambari UI to enable/disable SSL.
    #Allowed values ZOOKEEPER,AMS,HDFS,YARN,MAPREDUCE,OOZIE,HBASE,SPARK,HIVE,KAFKA
    ADDITIONAL_SSL_SERVICES=NONE
    #Whether to restart all the required services after certificate deployment
    RESTART_REQUIRED_SERVICES=false
    #Certificate validity in days. Mostly used for self signed certificates
    CERTIFICATE_VALIDITY=180
    #Bits to be used for certificate generation. Mostly used for self signed certificates
    CERTIFICATE_BITS=3072
    #Algorithm to be used for generating self signed certificate
    CERTIFICATE_ALGORITHM=sha256
    #Default path to store all the certificate, keys and keystore. Same path will be used for hadoop credential store
    CERT_PATH=/etc/security/serverKeys
    #Temporary certificate directory. Will be used before applying the certificate
    TEMP_CERT_PATH=/etc/security/serverKeys_new
    #Initital certificate generation path. Used only when generating self signed certificates
    CERT_GEN_FOLDER=/etc/security/serverKeys_cert_gen
    #Secure password location. This location will be used only during transaction
    CERT_PASS_PATH=/etc/security/certPass
    #Whether to take backup when doing certificate renewal. Mostly used for self signed certificates
    KEEP_OLD_CERTS=true
    #Set this flag incase utility used for older cluster. It will update the keystore path along with other properties
    LEGACY_CLUSTER=false
    #Set Keystore type
    KEYSTORE_TYPE=jks
     
    #This is completely owned by oracle. Leave this field unchanged
    ORACLE_OWNED_ROOT_CERTIFICATE_NAME=bdsOracleCA.crt
    ORACLE_OWNED_ROOT_CERTIFICATE_KEY_NAME=bdsOracleCA.key
     
    #Final trust bundle that contains all the trust certificates.
    #Including all public ca root certs, oracle owned root certs and customer specified root certs.
    #This will be saved in CERT_PATH. Leave this field untouched
    TRUST_CERTS_BUNDLE_NAME=oraclerootCA.crt
     
    #Root Certificate related details
    ROOT_CERT_PATH=/etc/security/serverKeys/bdsOracleCA.crt
     
    #Server certificate details
    SERVER_CERT_PATH="NONE"
    SERVER_CERT_KEY_PATH="NONE"
     
    #Support for LDAPS
    LDAP_URL=NONE
  6. Atualize o valor da propriedade CUSTOM_CERTIFICATE para true. Essa propriedade indica à ferramenta de utilitário que o certificado configurado é um certificado assinado por CA.
  7. Atualize a propriedade SERVER_CERT_PATH com o caminho do certificado para cada nó ou nó direcionado (suportado no Big Data Service versão 3.0.15 ou posterior) do cluster em uma lista separada por vírgulas no formato:
    <hostname>:<path/to/cert.crt>

    em que, hostname é o nó para o qual o certificado é copiado

    e <path/to/cert.crt> é o caminho completo para o arquivo de certificado e não o caminho relativo.

    Por exemplo:

    my-mn0-host.com:/tmp/my-mn0-host.com.crt,my-mn1-host.com:/tmp/my-mn1-host.com.crt
  8. Atualize a propriedade SERVER_CERT_KEY_PATH com o caminho da chave privada para cada nó ou nó direcionado (suportado no Big Data Service versão 3.0.15 ou posterior) do cluster em uma lista separada por vírgulas no formato:
    <hostname>:<path/to/cert.key>

    em que hostname é o nó para o qual a chave privada é copiada

    e <path/to/cert.key> é o caminho completo para a chave privada e não o caminho relativo.

    Por exemplo:

    my-mn0-host.com:/tmp/my-mn0-host.com.key,my-mn1-host.com:/tmp/my-mn1-host.com.key
  9. Validar se o certificado de cadeia de certificados CA adequado está presente no arquivo cert especificado no arquivo de configuração (Certificado do servidor > Certificados intermediários > Certificado raiz):
    # openssl crl2pkcs7 -nocrl -certfile bundle.cert.pem | openssl pkcs7 -print_certs -noout 

     bundle.cert.pem com o certificado root_ca.

    Por exemplo:

    [root@server1.oracle.com certs]# openssl crl2pkcs7 -nocrl -certfile bundle.cert.pem | openssl pkcs7 -print_certs -noout
    
    subject=/C=US/ST=CA/L=San Francisco/O=Example Corp/OU=IT Department/CN=www.example.com
    issuer=/C=US/ST=CA/O=Example Corp/OU=IT Department/CN=Intermediate CA 
    
    subject=/C=US/ST=CA/O=Example Corp/OU=IT Department/CN=Intermediate CA
    issuer=/C=US/ST=CA/L=San Francisco/O=Example Corp/OU=IT Department/CN=Root CA/emailAddress=Email Address 
    
    
    subject=/C=US/ST=CA/L=San Francisco/O=Example Corp/OU=IT Department/CN=Root CA/emailAddress=Email Address
    issuer=/C=US/ST=CA/L=San Francisco/O=Example Corp/OU=IT Department/CN=Root CA/emailAddress=Email Address   
    Observação

    Às vezes, você pode precisar importar o certificado KDC do Active Directory para fazer kerberização do cluster. Especifique o caminho do certificado (que contém a cadeia completa de certificados CA do Active Directory KDC) em ROOT_CERT_PATH.
    Por exemplo:
    1. Verifique a cadeia de certificados completa para a conexão SSL do KDC do Active Directory:
      openssl s_client -connect ldaps_server_name:port -showcerts 
    2. Confirme se o certificado disponível está definido em 'ROOT_CERT_PATH' e se ele tem todas as informações da cadeia de certificados do comando anterior.
  10. Atualize a propriedade ADDITIONAL_SSL_SERVICES com os serviços para os quais você deseja ativar o SSL. O valor padrão dessa propriedade é NONE. Os valores permitidos são AMS, HDFS, YARN, MAPREDUCE, OOZIE, HBASE, SPARK, ZOOKEEPER, HIVE e KAFKA. Recomendamos que você ative o SSL para todos os serviços obrigatórios de uma só vez usando uma lista dos serviços separados por vírgulas.
  11. Atualize LDAP_URL para apontar para o URL do servidor LDAP (aplicável somente para LDAP seguro), se o cluster ODH estiver integrado com LDAP/AD.

    Exemplo:

    LDAP_URL=ldaps://<myldap.com:636>

    Isso extrai automaticamente os certificados necessários para o armazenamento confiável ODH.

  12. Atualize o valor da propriedade RESTART_REQUIRED_SERVICES para true, se quiser que esse utilitário reinicie os serviços. O valor padrão dessa propriedade é false. Se você mantiver o valor padrão, reinicie manualmente todos os serviços afetados do Apache Ambari para concluir a ativação do SSL no cluster.
    Independentemente do valor desta propriedade, alguns serviços, como o Apache Ambari, são imediatamente reiniciados quando você ativa certificados usando este utilitário.
  13. Mantenha o valor padrão true da propriedade KEEP_OLD_CERTS para manter um backup dos certificados antigos. Os backups de certificados são armazenados em /etc/security/serverKeys-backup-<dateofbackup>.
  14. Se a versão do cluster for 3.0.6 ou anterior, defina o valor da propriedade LEGACY_CLUSTER como true para atualizar as propriedades de SSL no cluster. Ignore esta etapa se a versão do cluster for 3.0.7 ou posterior.
  15. Salve as alterações feitas no arquivo de configuração.
  16. Execute o utilitário para ativar os certificados SSL. Se você não usar os parâmetros ambariPass e keyPass, será solicitado que digite a senha do Ambari e a frase-senha da chave privada. Se nenhuma frase-senha de chave privada tiver sido fornecida quando a chave privada tiver sido gerada, você não precisará fornecer a frase-senha.
    sudo bds_cert_util --enable --ambariPass ambari-password --keyPass private-key-passphrase
  17. Aguarde a conclusão do utilitário.
  18. Revise os logs do utilitário em /home/opc/cloud/flask-microservice/logs/bds_cert_util*.log.
  19. Depois que o utilitário for executado com sucesso, todos os serviços configurados serão executados no SSL. Para verificar se os serviços estão ativados para SSL, faça sign-in no Apache Ambari e selecione os links rápidos de cada um dos serviços configurados.