milvus-logo
LFAI
Home
  • Leitfaden für die Verwaltung

Verschlüsselung bei der Übermittlung

TLS (Transport Layer Security) ist ein Verschlüsselungsprotokoll zur Gewährleistung der Kommunikationssicherheit. Milvus Proxy verwendet TLS für die einseitige und zweiseitige Authentifizierung.

In diesem Thema wird beschrieben, wie TLS in Milvus-Proxy sowohl für gRPC- als auch für RESTful-Verkehr aktiviert werden kann.

TLS und Benutzerauthentifizierung sind zwei unterschiedliche Sicherheitsansätze. Wenn Sie sowohl die Benutzerauthentifizierung als auch TLS in Ihrem Milvus-System aktiviert haben, müssen Sie einen Benutzernamen, ein Passwort und Pfade für Zertifikatsdateien angeben. Informationen zur Aktivierung der Benutzerauthentifizierung finden Sie unter Authentifizierung des Benutzerzugangs.

Erstellen Sie Ihr eigenes Zertifikat

Voraussetzungen

Stellen Sie sicher, dass OpenSSL installiert ist. Wenn Sie es nicht installiert haben, erstellen und installieren Sie zuerst OpenSSL.

openssl version

Wenn OpenSSL nicht installiert ist. Es kann mit dem folgenden Befehl in Ubuntu installiert werden.

sudo apt install openssl

Dateien erstellen

  1. Erstellen Sie die Dateien openssl.cnf und gen.sh.
mkdir cert && cd cert
touch openssl.cnf gen.sh
  1. Kopieren Sie die folgenden Konfigurationen in die jeweiligen Dateien.

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)

Die Datei openssl.cnf ist eine Standard-OpenSSL-Konfigurationsdatei. Weitere Informationen finden Sie auf der Handbuchseite. Die Datei gen.sh generiert relevante Zertifikatsdateien. Sie können die Datei gen.sh für verschiedene Zwecke modifizieren, z. B. um die Gültigkeitsdauer der Zertifikatsdatei, die Länge des Zertifikatsschlüssels oder die Namen der Zertifikatsdateien zu ändern.

Es ist notwendig, die CommonName in der Datei gen.sh zu konfigurieren. CommonName bezieht sich auf den Servernamen, den der Client beim Verbindungsaufbau angeben muss.

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

Die Variablen in der Datei gen.sh sind für den Prozess der Erstellung einer Zertifikatsignierungsanforderungsdatei entscheidend. Die ersten fünf Variablen sind die grundlegenden Signierinformationen, einschließlich Land, Staat, Ort, Organisation und Organisationseinheit. Bei der Konfiguration von CommonName ist Vorsicht geboten, da sie während der Client-Server-Kommunikation überprüft wird.

Führen Sie gen.sh aus, um ein Zertifikat zu erzeugen

Führen Sie die Datei gen.sh aus, um das Zertifikat zu erstellen.

chmod +x gen.sh
./gen.sh

Die folgenden neun Dateien werden erstellt: ca.key, ca.pem, ca.srl, server.key, server.pem, server.csr, client.key, client.pem, client.csr.

Ändern Sie die Details der Zertifikatsdateien (optional)

Nachdem Sie das Zertifikat erstellt haben, können Sie die Details der Zertifikatsdateien nach Ihren eigenen Bedürfnissen ändern.

An der Implementierung der gegenseitigen SSL- oder TSL-Authentifizierung sind ein Client, ein Server und eine Zertifizierungsstelle (CA) beteiligt. Eine CA wird verwendet, um sicherzustellen, dass das Zertifikat zwischen einem Client und einem Server legal ist.

Führen Sie man openssl aus oder lesen Sie die openssl-Handbuchseite für weitere Informationen über die Verwendung des OpenSSL-Befehls.

  1. Erzeugen Sie einen privaten RSA-Schlüssel für die CA.
openssl genpkey -algorithm RSA -out ca.key
  1. Fordern Sie die Generierung eines CA-Zertifikats an.

In diesem Schritt müssen Sie die grundlegenden Informationen über die Zertifizierungsstelle angeben. Wählen Sie die Option x509, um die Anforderung zu überspringen und direkt ein selbstsignierendes Zertifikat zu erzeugen.

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"

Sie erhalten eine ca.pem Datei, ein CA-Zertifikat, das nach diesem Schritt zur Erzeugung von Client-Server-Zertifikaten verwendet werden kann.

  1. Erzeugen Sie einen privaten Schlüssel für den Server.
openssl genpkey -algorithm RSA -out server.key

Nach diesem Schritt erhalten Sie eine server.key Datei.

  1. Generieren Sie eine Zertifikatssignierungsanforderungsdatei.

Sie müssen die erforderlichen Informationen über den Server angeben, um eine Zertifikatssignierungsanforderungsdatei zu erzeugen.

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

Nach diesem Schritt erhalten Sie eine server.csr Datei.

  1. Signieren Sie das Zertifikat.

Öffnen Sie die Dateien server.csr, ca.key und ca.pem, um das Zertifikat zu signieren. Die Befehlsoption CAcreateserial wird verwendet, um eine CA-Seriennummerndatei zu erstellen, falls sie nicht existiert. Sie erhalten eine aca.srl Datei, nachdem Sie diese Befehlsoption gewählt haben.

openssl x509 -req -days 3650 -in server.csr -out server.pem -CA ca.pem -CAkey ca.key -CAcreateserial -extfile ./openssl.cnf -extensions v3_req

Einrichten eines Milvus-Servers mit TLS

In diesem Abschnitt werden die Schritte zur Konfiguration eines Milvus-Servers mit TLS-Verschlüsselung beschrieben.

Diese Anleitung konzentriert sich auf die Bereitstellung mit Docker Compose. Informationen zur Bereitstellung von Milvus Operator finden Sie in der Milvus Operator TLS-Dokumentation.

1. Ändern Sie die Konfiguration des Milvus-Servers

Um TLS zu aktivieren, setzen Sie common.security.tlsMode in milvus.yaml auf 1 (für einseitiges TLS) oder 2 (für zweiseitiges TLS).

tls:
  serverPemPath: /milvus/tls/server.pem
  serverKeyPath: /milvus/tls/server.key
  caPemPath: /milvus/tls/ca.pem

common:
  security:
    tlsMode: 1

Parameter:

  • serverPemPath: Der Pfad zur Serverzertifikatsdatei.
  • serverKeyPath: Der Pfad zur Server-Schlüsseldatei.
  • caPemPath: Der Pfad zur CA-Zertifikatsdatei.
  • tlsMode: Der TLS-Modus für die Verschlüsselung. Gültige Werte:
    • 1: Einseitige Authentifizierung, bei der nur der Server ein Zertifikat benötigt und der Client es verifiziert. Dieser Modus erfordert server.pem und server.key auf der Serverseite und server.pem auf der Clientseite.
    • 2: Zwei-Wege-Authentifizierung, bei der sowohl der Server als auch der Client Zertifikate benötigen, um eine sichere Verbindung herzustellen. Für diesen Modus sind server.pem, server.key und ca.pem auf der Serverseite und client.pem, client.key und ca.pem auf der Clientseite erforderlich.

2. Zertifikatsdateien dem Container zuordnen

Vorbereiten der Zertifikatsdateien

Erstellen Sie einen neuen Ordner namens tls im gleichen Verzeichnis wie docker-compose.yaml. Kopieren Sie die Dateien server.pem, server.key, und ca.pem in den Ordner tls. Legen Sie sie in einer Verzeichnisstruktur wie folgt ab:

├── docker-compose.yml
├── milvus.yaml
└── tls
     ├── server.pem
     ├── server.key
     └── ca.pem

Aktualisieren Sie die Konfiguration von Docker Compose

Bearbeiten Sie die Datei docker-compose.yaml, um die Pfade der Zertifikatsdateien innerhalb des Containers wie unten gezeigt zuzuordnen:

  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

Bereitstellen von Milvus mit Docker Compose

Führen Sie den folgenden Befehl aus, um Milvus bereitzustellen:

sudo docker compose up -d

Verbinden Sie sich mit dem Milvus-Server mit TLS

Verwenden Sie für SDK-Interaktionen je nach TLS-Modus die folgenden Konfigurationen.

Einseitige TLS-Verbindung

Geben Sie den Pfad zu server.pem an und stellen Sie sicher, dass server_name mit dem im Zertifikat konfigurierten CommonName übereinstimmt.

from pymilvus import MilvusClient

client = MilvusClient(
    uri="https://localhost:19530",
    secure=True,
    server_pem_path="path_to/server.pem",
    server_name="localhost"
)

Zweiseitige TLS-Verbindung

Geben Sie die Pfade zu client.pem, client.key und ca.pem an und stellen Sie sicher, dass server_name mit dem im Zertifikat konfigurierten CommonName übereinstimmt.

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"
)

Siehe example_tls1.py und example_tls2.py für weitere Informationen.

Verbinden mit dem Milvus RESTful Server mit TLS

Für RESTful-APIs können Sie tls mit dem Befehl curl überprüfen.

Einseitige TLS-Verbindung

curl --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list

Zwei-Wege-TLS-Verbindung

curl --cert path_to/client.pem --key path_to/client.key --cacert path_to/ca.pem https://localhost:19530/v2/vectordb/collections/list

Übersetzt vonDeepL

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

War diese Seite hilfreich?