Cifrado en tránsito
TLS (Transport Layer Security) es un protocolo de encriptación para garantizar la seguridad de las comunicaciones. Milvus proxy utiliza la autenticación TLS unidireccional y bidireccional.
Este tema describe cómo habilitar TLS en Milvus proxy tanto para tráfico gRPC como RESTful.
TLS y la autenticación de usuario son dos enfoques de seguridad distintos. Si ha habilitado tanto la autenticación de usuario como TLS en su sistema Milvus, necesitará proporcionar un nombre de usuario, contraseña y rutas de archivos de certificado. Para obtener información sobre cómo habilitar la autenticación de usuario, consulte Autenticar el acceso de usuarios.
Cree su propio certificado
Requisitos previos
Asegúrese de que OpenSSL está instalado. Si no lo ha instalado, compile e instale OpenSSL en primer lugar.
openssl version
Si OpenSSL no está instalado. Se puede instalar con el siguiente comando en Ubuntu.
sudo apt install openssl
Crear archivos
- Cree los archivos
openssl.cnfygen.sh.
mkdir cert && cd cert
touch openssl.cnf gen.sh
- Copie las siguientes configuraciones en los archivos respectivamente.
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)
El archivo openssl.cnf es un archivo de configuración de OpenSSL por defecto. Consulte la página del manual para obtener más información. El archivo gen.sh genera los archivos de certificado pertinentes. Puede modificar el archivo gen.sh para distintos fines, como cambiar el periodo de validez del archivo de certificado, la longitud de la clave del certificado o los nombres de los archivos de certificado.
Es necesario configurar CommonName en el archivo gen.sh. El CommonName se refiere al nombre del servidor que el cliente debe especificar al conectarse.
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
Las variables del archivo gen.sh son cruciales para el proceso de creación de un archivo de solicitud de firma de certificado. Las primeras cinco variables son la información básica de firma, incluyendo país, estado, ubicación, organización, unidad de organización. Hay que tener cuidado al configurar CommonName, ya que se verificará durante la comunicación cliente-servidor.
Ejecute gen.sh para generar el certificado
Ejecute el archivo gen.sh para crear el certificado.
chmod +x gen.sh
./gen.sh
Se crearán los nueve archivos siguientes: ca.key, ca.pem, ca.srl, server.key, server.pem, server.csr, client.key, client.pem, client.csr.
Modificar los detalles de los archivos de certificado (opcional)
Después de generar el certificado, puede modificar los detalles de los archivos de certificado según sus propias necesidades.
La implementación de la autenticación mutua SSL o TSL implica un cliente, un servidor y una autoridad de certificación (CA). Una CA se utiliza para garantizar que el certificado entre un cliente y un servidor es legal.
Ejecute man openssl o consulte la página del manual de openssl para obtener más información sobre el uso del comando OpenSSL.
- Generar una clave privada RSA para la ca.
openssl genpkey -algorithm RSA -out ca.key
- Solicite la generación del certificado CA.
En este paso debe proporcionar la información básica sobre la CA. Elija la opción x509 para omitir la solicitud y generar directamente un certificado autofirmado.
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"
Obtendrá un archivo ca.pem, un certificado de CA que se puede utilizar para generar certificados cliente-servidor después de este paso.
- Genere una clave privada de servidor.
openssl genpkey -algorithm RSA -out server.key
Obtendrá un archivo server.key después de este paso.
- Generar un archivo de solicitud de firma de certificado.
Debe proporcionar la información necesaria sobre el servidor para generar un archivo de solicitud de firma de certificado.
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
Obtendrá un archivo server.csr después de este paso.
- Firme el certificado.
Abra los archivos server.csr, ca.key y ca.pem para firmar el certificado. La opción de comando CAcreateserial se utiliza para crear un archivo de número de serie de CA si no existe. Obtendrá un archivo aca.srl después de elegir esta opción de comando.
openssl x509 -req -days 3650 -in server.csr -out server.pem -CA ca.pem -CAkey ca.key -CAcreateserial -extfile ./openssl.cnf -extensions v3_req
Configurar un servidor Milvus con TLS
Esta sección describe los pasos para configurar un servidor Milvus con encriptación TLS.
Esta guía se centra en el despliegue utilizando Docker Compose. Para obtener información sobre el despliegue de Milvus Operator, consulte la documentación de Milvus Operator TLS.
1. Modifique la configuración del servidor Milvus
Para habilitar TLS, establezca common.security.tlsMode en milvus.yaml a 1 (para TLS unidireccional) o 2 (para TLS bidireccional).
tls:
serverPemPath: /milvus/tls/server.pem
serverKeyPath: /milvus/tls/server.key
caPemPath: /milvus/tls/ca.pem
common:
security:
tlsMode: 1
Parámetros:
serverPemPath: La ruta al archivo del certificado del servidor.serverKeyPath: La ruta al archivo de claves del servidor.caPemPath: La ruta al archivo del certificado de la CA.tlsMode: El modo TLS para el cifrado. Valores válidos:1: Autenticación unidireccional, donde sólo el servidor requiere un certificado y el cliente lo verifica. Este modo requiereserver.pemyserver.keydel lado del servidor, yserver.pemdel lado del cliente.2: Autenticación bidireccional, en la que tanto el servidor como el cliente necesitan certificados para establecer una conexión segura. Este modo requiereserver.pem,server.key, yca.pempor parte del servidor, yclient.pem,client.key, yca.pempor parte del cliente.
2. Asignar archivos de certificado al contenedor
Prepare los archivos de certificado
Cree una nueva carpeta llamada tls en el mismo directorio que docker-compose.yaml. Copie los archivos server.pem, server.key, y ca.pem en la carpeta tls. Colóquelos en una estructura de directorios como la siguiente:
├── docker-compose.yml
├── milvus.yaml
└── tls
├── server.pem
├── server.key
└── ca.pem
Actualizar la configuración de Docker Compose
Edite el archivo docker-compose.yaml para asignar las rutas de los archivos de certificado dentro del contenedor como se muestra a continuación:
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
Despliegue de Milvus utilizando Docker Compose
Ejecute el siguiente comando para desplegar Milvus:
sudo docker compose up -d
Conectarse al servidor Milvus con TLS
Para las interacciones SDK, utilice las siguientes configuraciones dependiendo del modo TLS.
Conexión TLS unidireccional
Proporcione la ruta a server.pem y asegúrese de que server_name coincide con CommonName configurado en el certificado.
from pymilvus import MilvusClient
client = MilvusClient(
uri="https://localhost:19530",
secure=True,
server_pem_path="path_to/server.pem",
server_name="localhost"
)
Conexión TLS bidireccional
Proporcione las rutas a client.pem, client.key, y ca.pem, y asegúrese de que server_name coincide con CommonName configurada en el certificado.
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"
)
Consulte example_tls1.py y example_tls2.py para obtener más información.
Conectarse al servidor RESTful de Milvus con TLS
Para las API RESTful, puede comprobar tls utilizando el comando curl.
Conexión TLS unidireccional
curl --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list
Conexión TLS bidireccional
curl --cert path_to/client.pem --key path_to/client.key --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list
