Encriptação em trânsito
O TLS (Transport Layer Security) é um protocolo de encriptação que garante a segurança das comunicações. O proxy Milvus utiliza a autenticação unidirecional e bidirecional TLS.
Este tópico descreve como ativar o TLS no proxy Milvus para os tráfegos gRPC e RESTful.
O TLS e a autenticação do utilizador são duas abordagens de segurança distintas. Se tiver ativado a autenticação do utilizador e o TLS no seu sistema Milvus, terá de fornecer um nome de utilizador, uma palavra-passe e caminhos de ficheiros de certificados. Para obter informações sobre como ativar a autenticação do utilizador, consulte Autenticar o acesso do utilizador.
Criar seu próprio certificado
Pré-requisitos
Certifique-se de que o OpenSSL esteja instalado. Se não o tiver instalado, compile e instale o OpenSSL primeiro.
openssl version
Se o OpenSSL não estiver instalado. Ele pode ser instalado com o seguinte comando no Ubuntu.
sudo apt install openssl
Criar ficheiros
- Crie os ficheiros
openssl.cnfegen.sh.
mkdir cert && cd cert
touch openssl.cnf gen.sh
- Copie as seguintes configurações para os ficheiros, respetivamente.
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)
O arquivo openssl.cnf é um arquivo de configuração padrão do OpenSSL. Consulte a página de manual para obter mais informações. O arquivo gen.sh gera arquivos de certificado relevantes. É possível modificar o arquivo gen.sh para diferentes finalidades, como alterar o período de validade do arquivo de certificado, o comprimento da chave do certificado ou os nomes dos arquivos de certificado.
É necessário configurar o CommonName no ficheiro gen.sh. O CommonName refere-se ao nome do servidor que o cliente deve especificar durante a ligação.
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
As variáveis no ficheiro gen.sh são cruciais para o processo de criação de um ficheiro de pedido de assinatura de certificado. As primeiras cinco variáveis são as informações básicas de assinatura, incluindo país, estado, localização, organização e unidade organizacional. É necessário ter cuidado ao configurar o CommonName, pois ele será verificado durante a comunicação cliente-servidor.
Execute gen.sh para gerar o certificado
Execute o ficheiro gen.sh para criar o certificado.
chmod +x gen.sh
./gen.sh
Serão criados os seguintes nove ficheiros: ca.key, ca.pem, ca.srl, server.key, server.pem, server.csr, client.key, client.pem, client.csr.
Modificar os detalhes dos ficheiros de certificado (opcional)
Depois de gerar o certificado, pode modificar os detalhes dos ficheiros de certificado de acordo com as suas necessidades.
A implementação da autenticação mútua SSL ou TSL envolve um cliente, um servidor e uma autoridade de certificação (CA). Uma CA é utilizada para garantir que o certificado entre um cliente e um servidor é legal.
Execute man openssl ou consulte a página do manual do openssl para obter mais informações sobre como usar o comando OpenSSL.
- Gerar uma chave privada RSA para a CA.
openssl genpkey -algorithm RSA -out ca.key
- Solicitar a geração de um certificado CA.
Nesta etapa, é necessário fornecer as informações básicas sobre a CA. Escolha a opção x509 para ignorar o pedido e gerar diretamente um certificado auto-assinado.
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"
Obterá um ficheiro ca.pem, um certificado CA que pode ser utilizado para gerar certificados cliente-servidor após este passo.
- Gerar uma chave privada do servidor.
openssl genpkey -algorithm RSA -out server.key
Obterá um ficheiro server.key após este passo.
- Gerar um ficheiro de pedido de assinatura de certificado.
É necessário fornecer as informações necessárias sobre o servidor para gerar um ficheiro de pedido de assinatura 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
Irá obter um ficheiro server.csr após este passo.
- Assinar o certificado.
Abra os ficheiros server.csr, ca.key e ca.pem para assinar o certificado. A opção de comando CAcreateserial é utilizada para criar um ficheiro de número de série da CA, caso este não exista. Obterá um ficheiro aca.srl depois de escolher esta opção 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 um servidor Milvus com TLS
Esta secção descreve os passos para configurar um servidor Milvus com encriptação TLS.
Este guia concentra-se na implantação usando o Docker Compose. Para obter informações sobre a implantação do Milvus Operator, consulte a documentação do Milvus Operator TLS.
1. Modificar a configuração do servidor Milvus
Para ativar o TLS, defina common.security.tlsMode em milvus.yaml para 1 (para TLS unidirecional) ou 2 (para TLS bidirecional).
tls:
serverPemPath: /milvus/tls/server.pem
serverKeyPath: /milvus/tls/server.key
caPemPath: /milvus/tls/ca.pem
common:
security:
tlsMode: 1
Parâmetros:
serverPemPath: O caminho para o ficheiro de certificado do servidor.serverKeyPath: O caminho para o ficheiro de chave do servidor.caPemPath: O caminho para o ficheiro do certificado da CA.tlsMode: O modo TLS para encriptação. Valores válidos:1: Autenticação unidirecional, em que apenas o servidor requer um certificado e o cliente o verifica. Este modo requerserver.pemeserver.keydo lado do servidor, eserver.pemdo lado do cliente.2: Autenticação bidirecional, em que tanto o servidor como o cliente necessitam de certificados para estabelecer uma ligação segura. Este modo requerserver.pem,server.key, eca.pemdo lado do servidor, eclient.pem,client.key, eca.pemdo lado do cliente.
2. Mapear ficheiros de certificados para o contentor
Preparar ficheiros de certificados
Crie uma nova pasta com o nome tls no mesmo diretório que o seu docker-compose.yaml. Copie server.pem, server.key e ca.pem para a pasta tls. Coloque-os em uma estrutura de diretório como a seguir:
├── docker-compose.yml
├── milvus.yaml
└── tls
├── server.pem
├── server.key
└── ca.pem
Atualizar a configuração do Docker Compose
Edite o ficheiro docker-compose.yaml para mapear os caminhos do ficheiro de certificado dentro do contentor, conforme mostrado abaixo:
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
Implantar o Milvus usando o Docker Compose
Execute o seguinte comando para implantar o Milvus:
sudo docker compose up -d
Conectar-se ao servidor Milvus com TLS
Para interações SDK, utilize as seguintes configurações, dependendo do modo TLS.
Ligação TLS unidirecional
Forneça o caminho para server.pem e certifique-se de que server_name corresponde a CommonName configurado no certificado.
from pymilvus import MilvusClient
client = MilvusClient(
uri="https://localhost:19530",
secure=True,
server_pem_path="path_to/server.pem",
server_name="localhost"
)
Ligação TLS bidirecional
Forneça os caminhos para client.pem, client.key, e ca.pem, e certifique-se de que server_name corresponde a CommonName configurado no 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 e example_tls2.py para obter mais informações.
Ligar ao servidor Milvus RESTful com TLS
Para APIs RESTful, pode verificar o tls utilizando o comando curl.
Conexão TLS unidirecional
curl --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list
Ligação TLS bidirecional
curl --cert path_to/client.pem --key path_to/client.key --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list
