SSL pour les certificats signés par une autorité de certification

Un certificat d'autorité de certification est créé, signé et émis par un tiers ou une autorité de certification autorisé à valider l'identification du sujet du certificat. Dans les clusters Big Data Service avec la version 3.0.7 ou ultérieure, vous pouvez exécuter l'utilitaire de certificat Big Data Service afin d'utiliser des certificats SSL d'autorité de certification pour vos clusters ODH.

Remarque

  1. Oracle génère un certificat d'émetteur et l'ajoute au truststore sur les noeuds du cluster.
  2. Les clusters ODH Big Data Service prennent en charge l'ajout et le redimensionnement automatiques de noeuds à la demande. Pour les clusters activés avec des certificats SSL signés par une autorité de certification, lors de l'ajout d'un noeud, un certificat signé par Oracle est créé sur le nouveau noeud pour terminer le flux d'ajout de noeud. Les nouveaux noeuds ajoutés peuvent être mis à jour ultérieurement avec des certificats signés par l'autorité de certification.
  3. A partir de la version 3.0.15 de Big Data Service, ODH prend en charge la mise à jour des certificats signés par une autorité de certification pour les noeuds ciblés. Par exemple, un0 et mn0. Dans ce cas, vous devez fournir des certificats pour les noeuds ciblés et tous les autres noeuds utilisent des certificats signés Oracle.
  4. Les clusters créés avant la version 3.0.15 de Big Data Service requièrent des certificats pour tous les noeuds.

Activation de SSL pour les certificats signés par une autorité de certification

  1. Rassemblez les fichiers suivants dans un dossier et compressez le dossier au format .zip.
    • Certificat SSL signé par une autorité de certification pour chaque noeud ou noeud ciblé (pris en charge dans Big Data Service version 3.0.15 ou ultérieure) dans le cluster ODH en fonction du nom de domaine qualifié complet du noeud. Les certificats signés par une autorité de certification doivent être au format PEM (Privacy-Enhanced Mail) avec l'extension .crt.
    • Clé privée de chaque certificat avec l'extension .key.
    • Certificat racine du truststore.
  2. Connectez-vous via SSH au premier noeud maître (mn0) du noeud de cluster ODH en tant qu'utilisateur opc.
  3. Copiez le fichier ZIP vers le premier noeud maître (mn0).
    scp -i <node-key>
                                    <source/zip/filepath> opc@<mn0-public-ip>:<path/to/destination>
                                

    Exemple :

    scp -i ssh_login.key /home/test/certificates.zip opc@192.168.0.10:/tmp/certificates.zip
  4. Décompressez le fichier.
    unzip <filename>.zip -d </path/to/directory>
                                

    Exemple :

    unzip certificates.zip -d /tmp/certs
  5. Modifiez /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf.
    vi /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf
    Exemple :
    # 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. Mettez à jour la valeur de propriété CUSTOM_CERTIFICATE vers true. Cette propriété indique à l'outil utilitaire que le certificat configuré est signé par une autorité de certification.
  7. Mettez à jour la propriété SERVER_CERT_PATH avec le chemin de certificat pour chaque noeud ou noeud ciblé (pris en charge dans Big Data Service version 3.0.15 ou ultérieure) du cluster dans une liste séparée par des virgules au format suivant :
    
                                    <hostname>:<path/to/cert.crt>
                                

    hostname est le noeud vers lequel le certificat est copié ;

    et <path/to/cert.crt> est le chemin complet du fichier de certificat et non le chemin relatif.

    Exemple :

    my-mn0-host.com:/tmp/my-mn0-host.com.crt,my-mn1-host.com:/tmp/my-mn1-host.com.crt
  8. Mettez à jour la propriété SERVER_CERT_KEY_PATH avec le chemin de clé privée pour chaque noeud ou noeud ciblé (pris en charge dans Big Data Service version 3.0.15 ou ultérieure) du cluster dans une liste séparée par des virgules au format suivant :
    
                                    <hostname>:<path/to/cert.key>
                                

    hostname est le noeud vers lequel la clé privée est copiée ;

    et <path/to/cert.key> est le chemin complet de la clé privée et non le chemin relatif.

    Exemple :

    my-mn0-host.com:/tmp/my-mn0-host.com.key,my-mn1-host.com:/tmp/my-mn1-host.com.key
  9. Vérifiez que le certificat de chaîne de certificat d'autorité de certification approprié est présent dans le fichier de certificat transmis dans le fichier de configuration (certificat de serveur > certs intermédiaires > certificat racine) :
    # openssl crl2pkcs7 -nocrl -certfile bundle.cert.pem | openssl pkcs7 -print_certs -noout 

    bundle.cert.pem avec le certificat root_ca.

    Exemple :

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

    Parfois, vous pouvez avoir besoin d'importer le certificat KDC Active Directory pour kerberiser le cluster. Indiquez le chemin de certificat (contenant la chaîne de certificat CA complète du KDC Active Directory) dans ROOT_CERT_PATH.
    Exemple :
    1. Vérifiez la chaîne de certificats complète pour la connexion SSL KDC Active Directory :
      openssl s_client -connect ldaps_server_name:port -showcerts 
    2. Vérifiez que le certificat disponible est défini dans 'ROOT_CERT_PATH' et qu'il contient toutes les informations de chaîne de certificat de la commande précédente.
  10. Mettez à jour la propriété ADDITIONAL_SSL_SERVICES avec les services pour lesquels activer SSL. La valeur par défaut de cette propriété est NONE. Les valeurs autorisées sont AMS, HDFS, YARN, MAPREDUCE, OOZIE, HBASE, SPARK, ZOOKEEPER, HIVE et KAFKA. Nous vous recommandons d'activer SSL pour tous les services requis en une seule fois via une liste des services séparés par des virgules.
  11. Mettez à jour LDAP_URL pour qu'il pointe vers l'URL du serveur LDAP (applicable pour LDAP sécurisé uniquement), si le cluster ODH est intégré à LDAP/AD.

    Exemple :

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

    Cette opération extrait automatiquement les certificats requis vers le truststore ODH.

  12. Mettez à jour la valeur de propriété RESTART_REQUIRED_SERVICES vers true si vous voulez que cet utilitaire redémarre les services. La valeur par défaut de cette propriété est false. Si vous conservez la valeur par défaut, vous devez redémarrer manuellement tous les services concernés à partir d'Apache Ambari afin de terminer l'activation de SSL pour le cluster.
    Quelle que soit la valeur de cette propriété, peu de services, tels que Apache Ambari, sont immédiatement redémarrés lorsque vous activez des certificats à l'aide de cet utilitaire.
  13. Conservez la valeur par défaut true pour la propriété KEEP_OLD_CERTS afin de maintenir une sauvegarde des anciens certificats. Les sauvegardes de certificat sont stockées dans /etc/security/serverKeys-backup-<dateofbackup> .
  14. Si la version du cluster est 3.0.6 ou inférieure, définissez la valeur de propriété LEGACY_CLUSTER sur true pour mettre à jour les propriétés SSL dans le cluster. Ignorez cette étape si la version du cluster est 3.0.7 ou ultérieure.
  15. Enregistrez les modifications apportées au fichier de configuration.
  16. Exécutez l'utilitaire pour activer les certificats SSL. Si vous n'utilisez pas les paramètres ambariPass et keyPass, vous êtes invité à saisir le mot de passe Ambari et la phrase de passe de clé privée. Si aucune phrase de passe de clé privée n'a été fournie lors de la génération de la clé privée, vous n'avez pas besoin de la fournir.
    sudo bds_cert_util --enable --ambariPass ambari-password --keyPass private-key-passphrase
                                
  17. Attendez la fin de l'utilitaire.
  18. Consultez les journaux de l'utilitaire à partir de /bdslogs/bds_cert_util*.log.
  19. Une fois que l'utilitaire a terminé, tous les services configurés sont exécutés sur SSL. Pour vérifier si les services sont activés pour SSL, connectez- vous à Apache Ambari et sélectionnez les liaisons rapides sous chacun des services configurés.