SSL para certificados firmados por una autoridad de certificación (CA)

Un certificado de CA lo crea, firma y emite un tercero o una autoridad de certificación (CA) que está autorizada para validar la identificación del sujeto del certificado. En los clusters de Big Data Service con la versión 3.0.7 y versiones posteriores, puede ejecutar la herramienta de utilidad de certificado de Big Data Service para utilizar certificados SSL de CA para sus clusters de ODH.

Nota

  1. Oracle genera un certificado de emisor y lo agrega al almacén de confianza en los nodos del cluster.
  2. Los clusters de ODH de Big Data Service soportan la adición de nodos bajo demanda y la escala automática. Para los clusters activados con certificados SSL firmados por CA, durante la adición de nodos, se crea un certificado firmado por Oracle en el nuevo nodo para completar el flujo de adición de nodos. Los nodos recién agregados se pueden actualizar posteriormente con certificados firmados por CA.
  3. A partir de la versión 3.0.15 de Big Data Service, ODH soporta la actualización de certificados firmados por CA para nodos de destino. Por ejemplo, un0 y mn0. En estos casos, debe proporcionar certificados para los nodos de destino y todos los demás nodos utilizan certificados firmados por Oracle.
  4. Los clusters creados antes de la versión 3.0.15 de Big Data Service necesitan certificados para todos los nodos.

Activación de SSL para los certificados firmados por la autoridad de certificación (CA)

  1. Recopile los siguientes archivos en una carpeta y comprima la carpeta en formato .zip.
    • Certificado SSL firmado por CA para cada nodo o nodo de destino (compatible con Big Data Service versión 3.0.15 o posterior) en el cluster ODH basado en el FQDN del nodo. Los certificados firmados por CA deben tener el formato de correo con privacidad mejorada (PEM) con la extensión .crt.
    • La clave privada de cada certificado con la extensión .key.
    • Certificado raíz para el almacén de confianza.
  2. Utilice SSH para acceder al primer nodo maestro (mn0) del nodo de cluster de ODH como usuario opc.
  3. Copie el archivo zip en el primer nodo maestro (mn0).
    scp -i <node-key> <source/zip/filepath> opc@<mn0-public-ip>:<path/to/destination>

    Por ejemplo:

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

    Por ejemplo:

    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 ejemplo:
    # 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. Actualice el valor de la propiedad CUSTOM_CERTIFICATE a true. Esta propiedad indica a la herramienta de utilidad que el certificado configurado es un certificado firmado por una CA.
  7. Actualice la propiedad SERVER_CERT_PATH con la ruta de certificado para cada nodo o nodo de destino (compatible con Big Data Service versión 3.0.15 o posterior) del cluster en una lista separada por comas con el formato:
    <hostname>:<path/to/cert.crt>

    donde, hostname es el nodo en el que se copia el certificado

    y <path/to/cert.crt> es la ruta completa al archivo de certificado y no la ruta relativa.

    Por ejemplo:

    my-mn0-host.com:/tmp/my-mn0-host.com.crt,my-mn1-host.com:/tmp/my-mn1-host.com.crt
  8. Actualice la propiedad SERVER_CERT_KEY_PATH con la ruta de clave privada para cada nodo o nodo de destino (compatible con Big Data Service versión 3.0.15 o posterior) del cluster en una lista separada por comas con el formato:
    <hostname>:<path/to/cert.key>

    donde hostname es el nodo en el que se copia la clave privada

    y <path/to/cert.key> es la ruta completa a la clave privada y no la ruta relativa.

    Por ejemplo:

    my-mn0-host.com:/tmp/my-mn0-host.com.key,my-mn1-host.com:/tmp/my-mn1-host.com.key
  9. Valide que el certificado de cadena de certificados de CA correcto está presente en el archivo de certificado transferido en el archivo de configuración (Certificado de servidor > Certificados intermedios > Certificado raíz):
    # openssl crl2pkcs7 -nocrl -certfile bundle.cert.pem | openssl pkcs7 -print_certs -noout 

     bundle.cert.pem con el certificado root_ca.

    Por ejemplo:

    [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   
    Nota

    En ocasiones, puede que necesite importar el certificado KDC de Active Directory para kerberizar el cluster. Especifique la ruta de acceso del certificado (que contiene la cadena de certificados de CA completa del KDC de Active Directory) en ROOT_CERT_PATH.
    Por ejemplo:
    1. Verifique la cadena de certificados completa para la conexión SSL de KDC de Active Directory:
      openssl s_client -connect ldaps_server_name:port -showcerts 
    2. Confirme que el certificado disponible esté definido en 'ROOT_CERT_PATH' y que tenga toda la información de la cadena de certificados del comando anterior.
  10. Actualice la propiedad ADDITIONAL_SSL_SERVICES con los servicios para los que desea activar SSL. El valor por defecto de esta propiedad es NONE. Los valores permitidos son AMS, HDFS, YARN, MAPREDUCE, OOZIE, HBASE, SPARK, ZOOKEEPER, HIVE y KAFKA. Se recomienda activar SSL para todos los servicios necesarios de una vez mediante una lista separada por comas de los servicios.
  11. Actualice LDAP_URL para que apunte a la URL del servidor LDAP (aplicable solo para LDAP seguro), si el cluster de ODH está integrado con LDAP/AD.

    Ejemplo:

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

    Esto extrae automáticamente los certificados necesarios al almacén de confianza de ODH.

  12. Actualice el valor de la propiedad RESTART_REQUIRED_SERVICES a true si desea que esta utilidad reinicie los servicios. El valor por defecto de esta propiedad es false. Si conserva el valor por defecto, debe reiniciar manualmente todos los servicios afectados desde Apache Ambari para completar la activación de SSL para el cluster.
    Independientemente del valor de esta propiedad, pocos servicios como el Apache Ambari se reinician inmediatamente cuando se activan certificados mediante esta utilidad.
  13. Conserve el valor por defecto true para la propiedad KEEP_OLD_CERTS a fina de guardar una copia de seguridad de los certificados antiguos. Las copias de seguridad de certificados se almacenan en /etc/security/serverKeys-backup-<dateofbackup>.
  14. Si la versión del cluster es 3.0.6 o inferior, defina el valor de la propiedad LEGACY_CLUSTER en true para actualizar las propiedades SSL en el cluster. Omita este paso si la versión del cluster es 3.0.7 o posterior.
  15. Guarde los cambios realizados en el archivo de configuración.
  16. Ejecute la utilidad para activar los certificados SSL. Si no utiliza los parámetros ambariPass y keyPass, se le solicitará que introduzca la contraseña de Ambari y la frase de contraseña de clave privada. Si no se proporcionó ninguna frase de contraseña de clave privada cuando se generó la clave privada, no es necesario que proporcione la frase de contraseña.
    sudo bds_cert_util --enable --ambariPass ambari-password --keyPass private-key-passphrase
  17. Espere a que complete la utilidad.
  18. Revise los logs de la utilidad de /home/opc/cloud/flask-microservice/logs/bds_cert_util*.log.
  19. Una vez que la utilidad se ejecuta correctamente, todos los servicios configurados se ejecutan en SSL. Para verificar si los servicios están activados para SSL, conéctese a Apache Ambari y seleccione los enlaces rápidos de cada Uno de los servicios configurados.