clearml vs mlflow, security and cost matter.
clearml和mlflow都是流行的机器学习任务管理平台,可以很方便的管理各种AI实验.
之前用过clearML,但是发现mlflow相对而言架构更简洁一些.clearml由web api-server file-server三个服务构成,且对外暴露3个服务端口,api和file的server服务需要在用户端被web调用.这个架构最大的问题是安全性.暴露服务太多,攻击者很容易针对其中一个服务发起攻击.其次,需要SSL加密的话,要分别对三个服务端进行代理,运维难度和成本比较高.
mlflow的架构有点像django,仅对外暴露一个web服务端口,同时被浏览器与训练脚本复用.做SSL加密的复杂度大大降低.此外mlflow全面支持hyper-parameter auto tuning(私有部署也能用).
SSL/TLS
SSL/TLS 是一种加密协议，用于在网络上安全传输数据。是HTTPS的主流方案.
名词解释
简单来说普通的http是明文传输,并不安全,很容易受到中间人攻击或者窃听.主流方案是HTTP加SSL/TLS,也就是所谓的HTTPS.
现代加密技术一般设计非对称性加密的概念,简言之就是client和server各有一套密钥,可以在不暴露自身密钥的前提下相互验证.
.key文件是私钥,服务器或客户端的私钥，用于解密传输中的预主密钥。
.csr文件是证书签名请求.包含申请者的身份信息和公钥，向证书颁发机构（CA）申请数字证书。
.crt是由证书颁发机构（CA）签名的证书，包含服务器或客户端的公钥和身份信息。
通常来说,公钥是公开在网络上的,任何人都可以获取.A获取到B的公钥后,可以用公钥加密信息.那么只有持有该公钥对应私钥的B才能解开这条消息;私钥一般是严密保管的,可以用来生成公钥.
此外还有一个签名的概念,签名主要是发送方用私钥生成消息摘要(消息的hash值),接收方使用对应公钥计算消息摘要,验证消息的完整性和发送方的身份.另外,接收方也会用同样的hash算法自己计算一次消息摘要,确保消息与摘要是对应的.
SSL/TLS流程
-
客户端发起握手：客户端（如浏览器）向服务器发送一个 ClientHello 消息，其中包含客户端支持的 SSL/TLS 版本、加密算法列表和一个随机数。
-
服务器响应：服务器返回一个 ServerHello 消息，其中包含服务器选择的 SSL/TLS 版本、加密算法和一个随机数。服务器还会发送其数字证书（包含服务器的公钥）。
-
客户端验证服务器证书：客户端验证服务器的证书是否合法。如果证书通过验证，客户端会生成一个预主密钥，并使用服务器的公钥对其加密，然后将加密后的预主密钥发送给服务器。
-
服务器解密预主密钥：服务器使用自己的私钥解密预主密钥。
-
生成会话密钥：客户端和服务器使用预主密钥和之前交换的随机数生成会话密钥，用于对后续通信进行对称加密。
总结一下:
-
第一个来回,就是client告诉server要通信了,server和client确定一些metadata,比如SSL/TLS 版本、加密算法、随机数,server在返回时给client发送自己的.crt文件,证明自己的身份,client可以拿着server声称的公钥去证书机构那里查验.
-
第二个来回,client先拿着server的公钥去查了这个家伙不是李鬼,然后拿着李逵的公钥加密了一条"预主密钥"发给server.客户端和服务器共同使用预主密钥以及握手过程中交换的随机数生成会话密钥。这个会话密钥就是client和server后续通信的共同信物.
-
后续通信,会话密钥用于对客户端和服务器之间的所有通信进行加密和解密。这部分通常是对称加密，比如AES,相对好理解.
最后再总结一下就是:非对称加密生成"会话密钥".对称加密后续通讯内容.
CA
数字证书认证机构
CA (Certificate Authority) 验证
上文中,第二个来回,client先拿着server的公钥去查了这个家伙不是李鬼 这里有个细节,client是怎么确认server身份的呢?
客户端检查服务器证书的签发者是否是受信任的证书颁发机构（CA）。如果服务器证书是由中间证书颁发机构签署的，客户端会继续向上检查，直到根 CA。
验证的内容包括:
-
日期有效性：客户端检查服务器证书的有效期，确保证书在当前时间内是有效的。
-
证书吊销状态：客户端可以通过证书吊销列表（CRL）或在线证书状态协议（OCSP）检查服务器证书是否被吊销。
-
域名匹配：客户端检查证书中的域名（Common Name 或 Subject Alternative Name）是否与客户端试图连接的服务器域名匹配。
自签CA
大的CA机构证书一般是收费的,免费的也有,比如Let’s Encrypt,但一般一年就需要续一次.
自签证书最大的区别就是需要手动导入到浏览器或者其他client中,可信度仅限于特定的环境或系统，通常用于内部网络或测试环境。
机构CA和自签CA最大的区别其实就是机构为"域名–证书"的归属权做了背书.比如当网络上有不止一个声称是willtian.cn这个网站的公钥时,client就可以到机构那边的查验.如果是自签CA,那么权威性仅是个人背书(一般情况千万不要擅自把不明证书添加到信任域当中!).
作为学习,以自签CA为例,开始给私有部署的mlflow增加HTTPS反向代理.
实战
生成和签署服务器证书
- 生成 CA 私钥和 CA 证书：
##生成 CA 私钥
openssl genpkey -algorithm RSA -out ca.key`
# 生成自签名 CA 证书
openssl req -x509 -new -nodes -key ca.key -sha256 -days 1024 -out ca.crt -subj "/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=CA"- 生成服务器证书的私钥和证书签名请求( CSR)
# 生成服务器私钥
openssl genpkey -algorithm RSA -out server.key
# 生成服务器 CSR
openssl req -new -key server.key -out server.csr -subj "/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=your.server.name"- 使用 CA 证书签署服务器证书：
# 使用 CA 证书签署服务器证书
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 500 -sha256- 验证生成的服务器证书
openssl verify -CAfile ca.crt server.crt- 更新Nginx配置
server {
listen 443 ssl;
server_name your.server.name;
ssl_certificate /path/to/server.crt;
ssl_certificate_key /path/to/server.key;
ssl_client_certificate /path/to/ca.crt;
ssl_verify_client on;
location / {
try_files $uri $uri/ =404;
}
}重启Nginx 服务器以应用更改
生成客户端证书
- 生成客户端私钥和 CSR
openssl genpkey -algorithm RSA -out client.key
openssl req -new -key client.key -out client.csr -subj "/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=client"- 用 CA 签署客户端证书：
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 500 -sha256- 合并客户端证书和私钥到 PKCS12 文件：
openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt -name "Client Certificate"- 使用 curl 测试连接
控制变量,先用比较raw的方式,采用curl指令来检查我们链路是否走通了.
curl -v --cacert ca.crt --cert client.crt --key client.key https://your.server.name
返回200则证明我们的ca/server/client证书都是OK的,后续如果有其他应用层的错误可排查API参数等问题.
mlflow配置
按照官方手册.通过设置环境变量MLFLOW_TRACKING_SERVER_CERT_PATH和MLFLOW_TRACKING_SERVER_CERT_PATH即可.
管理各类ML实验很方便.
留言