Documentazione di Oracle Cloud Infrastructure

SSL per certificati firmati da autorità di certificazione (CA)

Un certificato CA viene creato, firmato ed emesso da una terza parte o da un'autorità di certificazione (CA) autorizzata a convalidare l'identificazione dell'oggetto del certificato. Nei cluster di Big Data Service con versione 3.0.7 e successive, è possibile eseguire lo strumento di utility dei certificati di Big Data Service per utilizzare i certificati SSL CA per i cluster ODH.

Nota

  1. Oracle genera un certificato dell'emittente e lo aggiunge al truststore sui nodi del cluster.
  2. I cluster ODH di Big Data Service supportano l'aggiunta e la scalabilità automatica dei nodi su richiesta. Per i cluster abilitati con certificati SSL firmati CA, durante l'aggiunta del nodo viene creato un certificato firmato Oracle sul nuovo nodo per completare il flusso di aggiunta del nodo. I nuovi nodi aggiunti possono essere aggiornati in seguito con i certificati firmati CA.
  3. A partire da Big Data Service versione 3.0.15, ODH supporta l'aggiornamento dei certificati firmati CA per i nodi di destinazione. Ad esempio, un0 e mn0. In questi casi, è necessario fornire certificati per i nodi di destinazione e tutti gli altri nodi utilizzano certificati firmati Oracle.
  4. I cluster creati prima di Big Data Service versione 3.0.15 richiedono certificati per tutti i nodi.

Abilitazione di SSL per i certificati firmati dall'autorità di certificazione (CA)

  1. Raccogliere i seguenti file in una cartella e comprimere la cartella in formato .zip.
    • Certificato SSL firmato dalla CA per ogni nodo o nodo di destinazione (supportato nel servizio Big Data versione 3.0.15 o successiva) nel cluster ODH in base al nome FQDN del nodo. I certificati firmati da CA devono essere in formato PEM (Privacy Enhanced Mail) con l'estensione .crt.
    • La chiave privata di ogni certificato con l'estensione .key.
    • Certificato radice per il truststore.
  2. SSH al primo nodo principale (mn0) del nodo cluster ODH come utente opc.
  3. Copiare il file zip nel primo nodo principale (mn0). 
    scp -i <node-key> <source/zip/filepath> opc@<mn0-public-ip>:<path/to/destination>

    esempio:

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

    esempio:

    unzip certificates.zip -d /tmp/certs
  5. Modificare /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf. 
    vi /home/opc/cloud/flask-microservice/cert_util/conf/bds-certs.conf
    esempio:
    # 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. Aggiornare il valore della proprietà CUSTOM_CERTIFICATE in true. Questa proprietà indica allo strumento di utility che il certificato configurato è un certificato firmato da CA.
  7. Aggiornare la proprietà SERVER_CERT_PATH con il percorso del certificato per ogni nodo o nodo di destinazione (supportato nel servizio Big Data versione 3.0.15 o successiva) del cluster in una lista separata da virgole nel formato seguente: 
    <hostname>:<path/to/cert.crt>

    dove, hostname è il nodo in cui viene copiato il certificato

    e, <path/to/cert.crt> è il percorso completo del file di certificato e non il percorso relativo.

    esempio:

    my-mn0-host.com:/tmp/my-mn0-host.com.crt,my-mn1-host.com:/tmp/my-mn1-host.com.crt
  8. Aggiornare la proprietà SERVER_CERT_KEY_PATH con il percorso della chiave privata per ogni nodo o nodo di destinazione (supportato nel servizio Big Data versione 3.0.15 o successiva) del cluster in una lista separata da virgole nel formato seguente: 
    <hostname>:<path/to/cert.key>

    dove, hostname è il nodo in cui viene copiata la chiave privata

    e, <path/to/cert.key> è il percorso completo della chiave privata e non il percorso relativo.

    esempio:

    my-mn0-host.com:/tmp/my-mn0-host.com.key,my-mn1-host.com:/tmp/my-mn1-host.com.key
  9. Verificare che il certificato della catena di certificati CA corretto sia presente nel file di certificato passato nel file di configurazione (certificato server > certificati intermedi > certificato radice): 
    # openssl crl2pkcs7 -nocrl -certfile bundle.cert.pem | openssl pkcs7 -print_certs -noout

     bundle.cert.pem con il certificato root_ca.

    esempio:

    [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

    A volte, potrebbe essere necessario importare il certificato KDC di Active Directory per la cherberizzazione del cluster. Specificare il percorso del certificato (contenente la catena di certificati CA completa del KDC di Active Directory) in ROOT_CERT_PATH.
    esempio:
    1. Verificare la catena di certificati completa per la connessione SSL al KDC Active Directory:
      openssl s_client -connect ldaps_server_name:port -showcerts
    2. Verificare che il certificato disponibile sia definito in 'ROOT_CERT_PATH' e che contenga tutte le informazioni sulla catena di certificati del comando precedente.
  10. Aggiornare la proprietà ADDITIONAL_SSL_SERVICES con i servizi per i quali si desidera abilitare SSL. Il valore predefinito di questa proprietà è NONE. I valori consentiti sono AMS, HDFS, YARN, MAPREDUCE, OOZIE, HBASE, SPARK, ZOOKEEPER, HIVE e KAFKA. Si consiglia di abilitare SSL per tutti i servizi richiesti in un'unica operazione utilizzando un elenco separato da virgole dei servizi.
  11. Aggiornare LDAP_URL in modo che punti all'URL del server LDAP (applicabile solo per LDAP sicuro), se il cluster ODH è integrato con LDAP/AD.

    Esempio:

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

    In questo modo i certificati richiesti vengono automaticamente estratti nel truststore ODH.

  12. Aggiornare il valore della proprietà RESTART_REQUIRED_SERVICES in true se si desidera che questa utility riavvii i servizi. Il valore predefinito per questa proprietà è false. Se si conserva il valore predefinito, è necessario riavviare manualmente tutti i servizi interessati da Apache Ambari per completare l'abilitazione di SSL per il cluster.
    Indipendentemente dal valore di questa proprietà, alcuni servizi come Apache Ambari vengono riavviati immediatamente quando si abilitano i certificati che utilizzano questa utility.
  13. Conservare il valore predefinito true per la proprietà KEEP_OLD_CERTS per mantenere un backup dei vecchi certificati. I backup dei certificati vengono memorizzati in /etc/security/serverKeys-backup-<dateofbackup>.
  14. Se la versione del cluster è 3.0.6 o successiva, impostare il valore della proprietà LEGACY_CLUSTER su true per aggiornare le proprietà SSL nel cluster. Saltare questo passo se la versione del cluster è la 3.0.7 o successiva.
  15. Salvare le modifiche apportate al file di configurazione.
  16. Eseguire la utility per abilitare i certificati SSL. Se non si utilizzano i parametri ambariPass e keyPass, viene richiesto di immettere la password Ambari e la passphrase della chiave privata. Se al momento della generazione della chiave privata non è stata fornita alcuna passphrase per la chiave privata, non è necessario fornire la passphrase. 
    sudo bds_cert_util --enable --ambariPass ambari-password --keyPass private-key-passphrase
  17. Attendere il completamento della utility.
  18. Esaminare i log della utility da /home/opc/cloud/flask-microservice/logs/bds_cert_util*.log.
  19. Una volta completata l'esecuzione della utility, tutti i servizi configurati vengono eseguiti su SSL. Per verificare se i servizi sono abilitati per SSL, accedere ad Apache Ambari e selezionare i collegamenti rapidi sotto ciascuno dei servizi configurati.