Cryptage en transit
TLS (Transport Layer Security) est un protocole de cryptage qui garantit la sécurité des communications. Le proxy Milvus utilise l'authentification unidirectionnelle et bidirectionnelle TLS.
Cette rubrique décrit comment activer TLS dans le proxy Milvus pour les trafics gRPC et RESTful.
TLS et l'authentification utilisateur sont deux approches de sécurité distinctes. Si vous avez activé l'authentification utilisateur et TLS dans votre système Milvus, vous devrez fournir un nom d'utilisateur, un mot de passe et des chemins d'accès aux fichiers de certificats. Pour plus d'informations sur l'activation de l'authentification de l'utilisateur, voir Authentifier l'accès de l'utilisateur.
Créer votre propre certificat
Conditions préalables
Assurez-vous qu'OpenSSL est installé. Si vous ne l'avez pas installé, compilez et installez d'abord OpenSSL.
openssl version
Si OpenSSL n'est pas installé. Il peut être installé avec la commande suivante dans Ubuntu.
sudo apt install openssl
Créer des fichiers
- Créez les fichiers
openssl.cnf
etgen.sh
.
mkdir cert && cd cert
touch openssl.cnf gen.sh
- Copiez les configurations suivantes dans les fichiers respectivement.
openssl.cnf
#
# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.
#
# This definition stops the following lines choking if HOME isn't
# defined.
HOME = .
RANDFILE = $ENV::HOME/.rnd
# Extra OBJECT IDENTIFIER info:
#oid_file = $ENV::HOME/.oid
oid_section = new_oids
# To use this configuration file with the "-extfile" option of the
# "openssl x509" utility, name here the section containing the
# X.509v3 extensions to use:
# extensions =
# (Alternatively, use a configuration file that has only
# X.509v3 extensions in its main [= default] section.)
[ new_oids ]
# We can add new OIDs in here for use by 'ca', 'req' and 'ts'.
# Add a simple OID like this:
# testoid1=1.2.3.4
# Or use config file substitution like this:
# testoid2=${testoid1}.5.6
# Policies used by the TSA examples.
tsa_policy1 = 1.2.3.4.1
tsa_policy2 = 1.2.3.4.5.6
tsa_policy3 = 1.2.3.4.5.7
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = ./demoCA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
# Comment out the following two lines for the "traditional"
# (and highly broken) format.
name_opt = ca_default # Subject Name options
cert_opt = ca_default # Certificate field options
# Extension copying option: use with caution.
copy_extensions = copy
# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs
# so this is commented out by default to leave a V1 CRL.
# crlnumber must also be commented out to leave a V1 CRL.
# crl_extensions = crl_ext
default_days = 365 # how long to certify for
default_crl_days= 30 # how long before next CRL
default_md = default # use public key default MD
preserve = no # keep passed DN ordering
# A few difference way of specifying how similar the request should look
# For type CA, the listed attributes must be the same, and the optional
# and supplied fields are just that :-)
policy = policy_match
# For the CA policy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
# For the 'anything' policy
# At this point in time, you must list all acceptable 'object'
# types.
[ policy_anything ]
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
####################################################################
[ req ]
default_bits = 2048
default_keyfile = privkey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_ca # The extentions to add to the self signed cert
# Passwords for private keys if not present they will be prompted for
# input_password = secret
# output_password = secret
# This sets a mask for permitted string types. There are several options.
# default: PrintableString, T61String, BMPString.
# pkix : PrintableString, BMPString (PKIX recommendation before 2004)
# utf8only: only UTF8Strings (PKIX recommendation after 2004).
# nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings).
# MASK:XXXX a literal mask value.
# WARNING: ancient versions of Netscape crash on BMPStrings or UTF8Strings.
string_mask = utf8only
req_extensions = v3_req # The extensions to add to a certificate request
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AU
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Some-State
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Internet Widgits Pty Ltd
# we can do this but it is not needed normally :-)
#1.organizationName = Second Organization Name (eg, company)
#1.organizationName_default = World Wide Web Pty Ltd
organizationalUnitName = Organizational Unit Name (eg, section)
#organizationalUnitName_default =
commonName = Common Name (e.g. server FQDN or YOUR name)
commonName_max = 64
emailAddress = Email Address
emailAddress_max = 64
# SET-ex3 = SET extension number 3
[ req_attributes ]
challengePassword = A challenge password
challengePassword_min = 4
challengePassword_max = 20
unstructuredName = An optional company name
[ usr_cert ]
# These extensions are added when 'ca' signs a request.
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This is required for TSA certificates.
# extendedKeyUsage = critical,timeStamping
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
[ v3_ca ]
# Extensions for a typical CA
# PKIX recommendation.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer
# This is what PKIX recommends but some broken software chokes on critical
# extensions.
#basicConstraints = critical,CA:true
# So we do this instead.
basicConstraints = CA:true
# Key usage: this is typical for a CA certificate. However since it will
# prevent it being used as an test self-signed certificate it is best
# left out by default.
# keyUsage = cRLSign, keyCertSign
# Some might want this also
# nsCertType = sslCA, emailCA
# Include email address in subject alt name: another PKIX recommendation
# subjectAltName=email:copy
# Copy issuer details
# issuerAltName=issuer:copy
# DER hex encoding of an extension: beware experts only!
# obj=DER:02:03
# Where 'obj' is a standard or added object
# You can even override a supported extension:
# basicConstraints= critical, DER:30:03:01:01:FF
[ crl_ext ]
# CRL extensions.
# Only issuerAltName and authorityKeyIdentifier make any sense in a CRL.
# issuerAltName=issuer:copy
authorityKeyIdentifier=keyid:always
[ proxy_cert_ext ]
# These extensions should be added when creating a proxy certificate
# This goes against PKIX guidelines but some CAs do it and some software
# requires this to avoid interpreting an end user certificate as a CA.
basicConstraints=CA:FALSE
# Here are some examples of the usage of nsCertType. If it is omitted
# the certificate can be used for anything *except* object signing.
# This is OK for an SSL server.
# nsCertType = server
# For an object signing certificate this would be used.
# nsCertType = objsign
# For normal client use this is typical
# nsCertType = client, email
# and for everything including object signing:
# nsCertType = client, email, objsign
# This is typical in keyUsage for a client certificate.
# keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# This will be displayed in Netscape's comment listbox.
nsComment = "OpenSSL Generated Certificate"
# PKIX recommendations harmless if included in all certificates.
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer
# This stuff is for subjectAltName and issuerAltname.
# Import the email address.
# subjectAltName=email:copy
# An alternative to produce certificates that aren't
# deprecated according to PKIX.
# subjectAltName=email:move
# Copy subject details
# issuerAltName=issuer:copy
#nsCaRevocationUrl = http://www.domain.dom/ca-crl.pem
#nsBaseUrl
#nsRevocationUrl
#nsRenewalUrl
#nsCaPolicyUrl
#nsSslServerName
# This really needs to be in place for it to be a proxy certificate.
proxyCertInfo=critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo
####################################################################
[ tsa ]
default_tsa = tsa_config1 # the default TSA section
[ tsa_config1 ]
# These are used by the TSA reply generation only.
dir = ./demoCA # TSA root directory
serial = $dir/tsaserial # The current serial number (mandatory)
crypto_device = builtin # OpenSSL engine to use for signing
signer_cert = $dir/tsacert.pem # The TSA signing certificate
# (optional)
certs = $dir/cacert.pem # Certificate chain to include in reply
# (optional)
signer_key = $dir/private/tsakey.pem # The TSA private key (optional)
default_policy = tsa_policy1 # Policy if request did not specify it
# (optional)
other_policies = tsa_policy2, tsa_policy3 # acceptable policies (optional)
digests = md5, sha1 # Acceptable message digests (mandatory)
accuracy = secs:1, millisecs:500, microsecs:100 # (optional)
clock_precision_digits = 0 # number of digits after dot. (optional)
ordering = yes # Is ordering defined for timestamps?
# (optional, default: no)
tsa_name = yes # Must the TSA name be included in the reply?
# (optional, default: no)
ess_cert_id_chain = no # Must the ESS cert id chain be included?
# (optional, default: no)
Le fichier openssl.cnf
est un fichier de configuration OpenSSL par défaut. Voir la page de manuel pour plus d'informations. Le fichier gen.sh
génère les fichiers de certificats appropriés. Vous pouvez modifier le fichier gen.sh
à différentes fins, par exemple pour changer la période de validité du fichier de certificat, la longueur de la clé de certificat ou les noms des fichiers de certificat.
Il est nécessaire de configurer le fichier CommonName
dans le fichier gen.sh
. Le CommonName
fait référence au nom du serveur que le client doit spécifier lors de la connexion.
gen.sh
#!/usr/bin/env sh
# your variables
Country="CN"
State="Shanghai"
Location="Shanghai"
Organization="milvus"
Organizational="milvus"
CommonName="localhost"
echo "generate ca.key"
openssl genrsa -out ca.key 2048
echo "generate ca.pem"
openssl req -new -x509 -key ca.key -out ca.pem -days 3650 -subj "/C=$Country/ST=$State/L=$Location/O=$Organization/OU=$Organizational/CN=$CommonName"
echo "generate server SAN certificate"
openssl genpkey -algorithm RSA -out server.key
openssl req -new -nodes -key server.key -out server.csr -days 3650 -subj "/C=$Country/O=$Organization/OU=$Organizational/CN=$CommonName" -config ./openssl.cnf -extensions v3_req
openssl x509 -req -days 3650 -in server.csr -out server.pem -CA ca.pem -CAkey ca.key -CAcreateserial -extfile ./openssl.cnf -extensions v3_req
echo "generate client SAN certificate"
openssl genpkey -algorithm RSA -out client.key
openssl req -new -nodes -key client.key -out client.csr -days 3650 -subj "/C=$Country/O=$Organization/OU=$Organizational/CN=$CommonName" -config ./openssl.cnf -extensions v3_req
openssl x509 -req -days 3650 -in client.csr -out client.pem -CA ca.pem -CAkey ca.key -CAcreateserial -extfile ./openssl.cnf -extensions v3_req
Les variables du fichier gen.sh
sont essentielles au processus de création d'un fichier de demande de signature de certificat. Les cinq premières variables sont les informations de signature de base, notamment le pays, l'état, l'emplacement, l'organisation et l'unité d'organisation. Il convient d'être prudent lors de la configuration de CommonName
, car ces informations seront vérifiées lors de la communication client-serveur.
Exécuter gen.sh
pour générer le certificat
Exécutez le fichier gen.sh
pour créer le certificat.
chmod +x gen.sh
./gen.sh
Les neuf fichiers suivants seront créés : ca.key
ca.pem
, ca.srl
, server.key
, server.pem
, server.csr
, client.key
, client.pem
, client.csr
.
Modifier les détails des fichiers de certificat (facultatif)
Après avoir généré le certificat, vous pouvez modifier les détails des fichiers de certificat en fonction de vos besoins.
La mise en œuvre de l'authentification mutuelle SSL ou TSL implique un client, un serveur et une autorité de certification (CA). Une autorité de certification est utilisée pour garantir que le certificat entre un client et un serveur est légal.
Exécutez man openssl
ou consultez la page de manuel openssl pour plus d'informations sur l'utilisation de la commande OpenSSL.
- Générer une clé privée RSA pour l'autorité de certification.
openssl genpkey -algorithm RSA -out ca.key
- Demander la génération d'un certificat CA.
Vous devez fournir les informations de base sur l'autorité de certification au cours de cette étape. Choisissez l'option x509
pour ignorer la demande et générer directement un certificat auto-signé.
openssl req -new -x509 -key ca.key -out ca.pem -days 3650 -subj "/C=$Country/ST=$State/L=$Location/O=$Organization/OU=$Organizational/CN=$CommonName"
Vous obtiendrez un fichier ca.pem
, un certificat CA qui peut être utilisé pour générer des certificats client-serveur après cette étape.
- Générez une clé privée de serveur.
openssl genpkey -algorithm RSA -out server.key
Vous obtiendrez un fichier server.key
après cette étape.
- Générer un fichier de demande de signature de certificat.
Vous devez fournir les informations requises sur le serveur pour générer un fichier de demande de signature de certificat.
openssl req -new -nodes -key server.key -out server.csr -days 3650 -subj "/C=$Country/O=$Organization/OU=$Organizational/CN=$CommonName" -config ./openssl.cnf -extensions v3_req
Vous obtiendrez un fichier server.csr
après cette étape.
- Signer le certificat.
Ouvrez les fichiers server.csr
, ca.key
et ca.pem
pour signer le certificat. L'option de commande CAcreateserial
est utilisée pour créer un fichier de numéro de série de l'autorité de certification s'il n'existe pas. Vous obtiendrez un fichier aca.srl
après avoir choisi cette option de commande.
openssl x509 -req -days 3650 -in server.csr -out server.pem -CA ca.pem -CAkey ca.key -CAcreateserial -extfile ./openssl.cnf -extensions v3_req
Configuration d'un serveur Milvus avec TLS
Cette section décrit les étapes de configuration d'un serveur Milvus avec le cryptage TLS.
Ce guide se concentre sur le déploiement à l'aide de Docker Compose. Pour plus d'informations sur le déploiement de Milvus Operator, reportez-vous à la documentation TLS de Milvus Operator.
1. Modifier la configuration du serveur Milvus
Pour activer TLS, définissez common.security.tlsMode
dans milvus.yaml
à 1
(pour TLS unidirectionnel) ou 2
(pour TLS bidirectionnel).
tls:
serverPemPath: /milvus/tls/server.pem
serverKeyPath: /milvus/tls/server.key
caPemPath: /milvus/tls/ca.pem
common:
security:
tlsMode: 1
Paramètres :
serverPemPath
: Le chemin d'accès au fichier de certificat du serveur.serverKeyPath
: Le chemin d'accès au fichier de clé du serveur.caPemPath
: Le chemin d'accès au fichier du certificat de l'autorité de certification.tlsMode
: Le mode TLS pour le cryptage. Valeurs valides :1
: Authentification unidirectionnelle, où seul le serveur a besoin d'un certificat et le client le vérifie. Ce mode nécessiteserver.pem
etserver.key
du côté du serveur, etserver.pem
du côté du client.2
: Authentification bidirectionnelle, où le serveur et le client ont tous deux besoin de certificats pour établir une connexion sécurisée. Ce mode nécessiteserver.pem
,server.key
, etca.pem
du côté serveur, etclient.pem
,client.key
, etca.pem
du côté client.
2. Mettez en correspondance les fichiers de certificats avec le conteneur
Préparer les fichiers de certificat
Créez un nouveau dossier nommé tls
dans le même répertoire que votre docker-compose.yaml
. Copiez les fichiers server.pem
, server.key
et ca.pem
dans le dossier tls
. Placez-les dans une structure de répertoire comme suit :
├── docker-compose.yml
├── milvus.yaml
└── tls
├── server.pem
├── server.key
└── ca.pem
Mise à jour de la configuration de Docker Compose
Modifiez le fichier docker-compose.yaml
pour mapper les chemins d'accès aux fichiers de certificats à l'intérieur du conteneur, comme indiqué ci-dessous :
standalone:
container_name: milvus-standalone
image: milvusdb/milvus:latest
command: ["milvus", "run", "standalone"]
security_opt:
- seccomp:unconfined
environment:
ETCD_ENDPOINTS: etcd:2379
MINIO_ADDRESS: minio:9000
volumes:
- ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
- ${DOCKER_VOLUME_DIRECTORY:-.}/tls:/milvus/tls
- ${DOCKER_VOLUME_DIRECTORY:-.}/milvus.yaml:/milvus/configs/milvus.yaml
Déployer Milvus à l'aide de Docker Compose
Exécutez la commande suivante pour déployer Milvus :
sudo docker compose up -d
Se connecter au serveur Milvus avec TLS
Pour les interactions SDK, utilisez les configurations suivantes en fonction du mode TLS.
Connexion TLS unidirectionnelle
Fournir le chemin d'accès à server.pem
et s'assurer que server_name
correspond à CommonName
configuré dans le certificat.
from pymilvus import MilvusClient
client = MilvusClient(
uri="https://localhost:19530",
secure=True,
server_pem_path="path_to/server.pem",
server_name="localhost"
)
Connexion TLS bidirectionnelle
Fournir les chemins d'accès à client.pem
, client.key
, et ca.pem
, et s'assurer que server_name
correspond à CommonName
configuré dans le certificat.
from pymilvus import MilvusClient
client = MilvusClient(
uri="https://localhost:19530",
secure=True,
client_pem_path="path_to/client.pem",
client_key_path="path_to/client.key",
ca_pem_path="path_to/ca.pem",
server_name="localhost"
)
Voir example_tls1.py et example_tls2.py pour plus d'informations.
Connexion au serveur RESTful Milvus avec TLS
Pour les API RESTful, vous pouvez vérifier tls à l'aide de la commande curl
.
Connexion TLS unidirectionnelle
curl --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list
Connexion TLS bidirectionnelle
curl --cert path_to/client.pem --key path_to/client.key --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list