Day19
Tidb的授权和认证
身份验证
服务器发送握手消息包
消息报包含服务器提供的capability
密码验证seed verification
客户端用握手响应进行应答
客户端自己的capability，使用使用双方的capability交集来决定协议的细节
可能会升级到SSL协议
客户端返回的消息中包含认证信息
用户名和主机
加密的密码
账户信息存储在哪里
账户相关信息存储在mysql.user这个表
服务器使用这些记录进行授权
为了提高性能，数据也缓存在内存中不要手动编辑该表，
如果需要，使用FLUSH权限来刷新缓存
标识是用户名+主机的组合
host是你来自的地方
%表示允许所有主机(默认)，无论您来自127.0.0.1或远程
172.16.4.42意味着用户“foo”只允许从172.16.4.42登录
密码如何加密
*3E4FB02A48EAB05B3811A78492A18C6FFCBF43CD这不是密码
密码没有以明文形式存储
在服务器中密码不是通过网络明文交换的
从概念上讲，authentication_string和原始密码可以看作是一对公钥和私钥。
服务器向客户机发送一个随机种子值。
客户端用私钥加密种子值，即原始密码。
服务器用公钥验证结果，即authentication_string。
TIDB使用MySQL 5.7中默认的认证方式mysql_native_password
严格地说，mysqlnative_password并没有真正使用公钥，
而私有密钥authentication_string只是转换后的散列(原始密码)
Authentication string= hash2(password)
服务器向客户机发送一个随机种子值
客户端回复hash2 (seed, hash:(password))
服务器验证结果hash1(seed，Authentication string)所选的哈希值是SHA1
用户权限
TIiDB提供了与MySQL相同的大多数权限
用户的权限决定了什么操作是允许的，以及用户可以访问哪个DB/Table
权限记录存储在mysql.user,mysql.db, mysql.tables_priv
GRANT select ON . TO ‘user’@’host’
全局权限存储在mysql.user
GRANT insert ON db.* to ’user’@’host’
数据库级别的权限存储在mysql.db中。
GRANT update ON db.table *’ to user’@’host’
表级权限存储在mysql.tables_priv中
TiDB不支持列级特权。
请求验证遵循以下步骤:
搜索全局级别权限
搜索数据库级别权限
搜索表级权限
RBAC 是基于角色的访问控制 tidb4.0以后提供
创建角色-赋予角色权限-创建用户-角色赋予用户-激活角色
激活角色sql(set default role to ‘dev1’@’localhost’ )
在此之后，用户拥有与角色相同的访问数据库的权限。
TLS和TED
TLS
TLS连接的传输层安全协议，互联网上保密通信的标准协议，有时称作SSL
TLS连接
加密的安全网络链接
经过身份验证的机制
可靠
证数
证书:一种数字文件(文件)，用来证明密钥的所有权
它由证书颁发机构(CA)签发
所有者向CA发送证书签署请求
CA证明密钥所有者的身份
CA签署证书
生成证书密钥方法
生成证书的方法通过公共CA(例如,Let’s encrypt)
适用于公共环境
自签名证书
通过像ssl-manager,cfssi这样的工具，或者手动通过openssl命令。
仅适用于受信任的环境。
在服务器/客户端之间使用安全连接
配置tidb
[security]
ssl-cert ="/path/to/tidb-cert.pem"
ssl-key="/path/to/tidb-key,pem"
如果TiDB启用它,mysql客户端>=5.7将使用安全连接
验证安全连接使用:
$ mysgl-h -u -p
mysqi> \s
…
SsL: cipher in use is ECDHE-RSA-AES128-GCM-SHA256
…
mysql> show status like ‘SSL%’;
…
Ssl_cipher | ECDHE-RSA-AES128-GCM-SHA256
Ssl-version | TLSv1.2
…
force secure connection-强制安全链接
方法1：Tidb服务器启动参数 --require-secure-transport
方法2:per-user 配置用require ssl
Mysql>create user ‘new_user’ require ssl;
Mysql>alter user ‘existing_user’ require ssl;
Mysql>grant all to ‘user1’ require ssl;
例子
$ mysgl-h -u user1 -p
mysqi> alter user ‘user1’ require ssl;
Qurey OK,0 rows affected (0.01 sec)
Mysql>quit
$ mysgl-h -u user1 -p --ssl-mode=disabled
Error 1045 (28000):Access denied for user ‘root’@’172.16.5.39’ (using password:NO)
$ mysgl-h -u user1 -p --ssl-mode=preferred
Mysql>
防止攻击服务器模仿tidb转发客户端的请求从而盗窃或者修改数据，需要客户端通过ca证书去确认自己链接的是tidb服务器
认证方法
配置tidb
[security]
ssl-ca ="/path/to/ca-cert.pem"
ssl-key="/path/to/tidb-key,pem"
例子
$ mysql -h -P -u user –ssl -ssl-ca=/path/to/ca-cert.pem
Mysql>
$mysql -h <fake_host> -P -u user1 –ssl-ca=/path/to/ca-cert.pem
Error 2016 (HY000):ssl connection error:
Error:0000001:lib(0):func(0):reason(1)
升级MySQL客户端到>= 5.7.3，并指定——SSL以避免BACKRONYM攻击(旧客户端可以静默地降级到不安全连接，使其容易受到man-in-the-middle 攻击)。
攻击者作为客户端直接攻击，对客户端身份认证
Tidb配置
[security]
ssl-cert ="/path/to/tidb-cert.pem"
ssl-key="/path/to/tidb-key.pem"
ssl-ca ="/path/to/ca-cert.pem"
例子
$mysql -h -P -u user1 \
– ssl-cert ="/path/to/tidb-cert.pem"\
–ssl-key="/path/to/tidb-key.pem"
mysql>
前面两个步骤的配置加起来就是双向认证 mutual TLS 也叫mTLS
[security]
ssl-cert ="/path/to/tidb-cert.pem"
ssl-key="/path/to/tidb-key.pem"
ssl-ca ="/path/to/ca-cert.pem"
例子
$mysql -h -P -u user1 \
– ssl-cert ="/path/to/tidb-cert.pem"\
–ssl-key="/path/to/tidb-key.pem"
– ssl-ca ="/path/to/ca-cert.pem"
mysql>
Tidb组件之间的TLS
TIDB配置
[security]
Cluster-ssl-cert ="/path/to/tidb-cert.pem"
Cluster-ssl-key="/path/to/tidb-key.pem"
Cluster-ssl-ca ="/path/to/ca-cert.pem"
PD配置
[security]
ssl-cert ="/path/to/pd-cert.pem"
ssl-key="/path/to/pd-key.pem"
ssl-ca ="/path/to/ca-cert.pem"
Tikv配置
[security]
ssl-cert ="/path/to/tikv-cert.pem"
ssl-key="/path/to/ tikv -key.pem"
ssl-ca ="/path/to/ca-cert.pem"
在线证书更换
例子
[security]
ssl-cert ="/path/to/tikv-cert.pem"
ssl-key="/path/to/ tikv -key.pem"
只需替换文件"/path/to/tidb-cert.pem"
不需要重启TiDB服务器
下次新的客户端连接到TiDB服务器时，将使用新的证书
不影响已连接的客户端TiDB/PD/TiKV都支持在线证书更换。
禁止客户端直接访问tikv
使用 common name
场景:
我们使用同一个CA证书签署了不同的证书
我们要限制,例如mysąl客户机只能访问TiDB
common name (CN)
common name :tidb-server
Tidb组件配置
TIDB配置
[security]
Cluster-ssl-cert ="/path/to/tidb-cert.pem"
Cluster-ssl-key="/path/to/tidb-key.pem"
Cluster-ssl-ca ="/path/to/ca-cert.pem"
Cluster-verify-cn=[“tidb-server”,”tikv-ctl”]
PD配置
[security]
ssl-cert ="/path/to/pd-cert.pem"
ssl-key="/path/to/pd-key.pem"
ssl-ca ="/path/to/ca-cert.pem"
cert-verify-cn=[“tikv-server”,”tidb-server”,”pd-ctl”]
Tikv配置
[security]
ssl-cert ="/path/to/tikv-cert.pem"
ssl-key="/path/to/ tikv -key.pem"
ssl-ca ="/path/to/ca-cert.pem"
cert-allowed-cn=[“tidb-server”,”pd-server”,”rawkv-client”]
保存到磁盘数据加密 TDE(静态数据加密)
也称为透明数据加密(TDE)
功能:加密数据存储在磁盘上
静止加密并不加密当前的数据
存储在内存中数据
网络中传输的数据
与文件系统或云供应商加密的差异
客户机必须通过TiDB进行身份验证才能访问，即使磁盘级别为pemission。
完全数据加密，而不是按列加密
Tikv节点上进行加密配置
AWS KMS CMK作为主密钥
KMS=key-mangement service密钥管理服务
使用专用硬件(HSM)存储主密钥。
主密钥永远不会暴露在硬件之外
Tikv 生产环境只有推荐的方式提供主钥匙 AWS KMS
Envelope Encryption—信封加密
主密钥-master key
AWS KMS key
用于加密数据密钥
用户自动管理
数据密钥-data key
由TiKV生成的加密安全随机字符串
用于加密数据文件
TikV自动滚动
信封加密的目的是支持密钥滚动
密钥滚动就是定期更换密钥
定期滚动 是为了减少密钥泄露时数据的泄密
主密钥如果滚动需要手动操作
需要重启tikv
瑕疵
核心转储文件会泄露数据
缓解:禁用TikV服务器的核心转储
PD不支持静止加密
使用文件系统级加密或其他静态加密解决方案
TiFlash还不支持静态加密
没有日志redation
数据可能打印到信息日志中
Storage.data-dir(以及其他数据目录)不可更改
云安全
第一部分:管理TiDB TLS证书
轻松安全地管理TIDB TLS证书
TIDB TLS的概述
mTLS用于组件间的传输加密
MySQL TLS用于SQL连接通信
K8s secret
K8s 保存敏感数据是secret
不要在源存储库中存储secret yaml文件
配置K8s集群时使用sercret 静态加密
使用RBAC限制用户对Secret的访问
从API层，它显示为base64编码的文本。它可以被kube apiserver加密存储到Etcd。在节点上，它存储在tmpfs中。
如何使用k8s secret
Monut secret as file
Reference secret in env
证书管理器
cert-manager: K8s中实际的证书管理工具，
支持从各种来源签发证书，
自动更新证书
使用简单和直观
Issuer 签名
证书 Certificate
证书请求 Certificate Request
使用证书管理器管理TiDB TLS证书
创建自签名issuer
创建自签名CA证书
使用CA证书创建issuer
为每个TiDB集群组件(PD/TiKV/TiDB/Pump/Drainer)创建一个服务器证书
创建客户端证书
配置TidbCluster spec.tiscluster.enabled to true
TLS secret的默认名称约定
server secret:${cluster_name}-${component_name}-cluster-secret。
Client secret:${cluster_name}-cluster-client-secret
CommonName (CN)验证:目前只支持一个CN
服务器证书支持在线更新
公有云的IAM系统
IAM包括两个基本功能 认证和授权
TiDB是一个云本地数据库:
TIDB支持直接备份到S3和GCS
TiDB可以使用AWS KMS加密TiKV数据
要访问像S3和KMS这样的云资源，我们需要凭据。$ aws s3 ls
TIKV在执行备份时直接对s3进行读写操作。如
何分发凭证?
如何滚动它们?
授权TiDB访问AWS资源的两个选项:
创建IAM user，并将AWS凭证存储在k8s Secret中
创建IAM role，并将该角色分配给TiDB pods
使用OIDC, AWs将权限委托给K8s apiserver
将K8s ServiceAccount与AWS role合并
如何在TIDB这样的分布式系统中安全地分发IAM凭证
对每个需要与云API交互的进程使用IAM role
使用EKS，使OIDC允许EKS apiserver向Pod分配角色和临时令牌
开启OIDC
创建IAM role for backup job
启用“k8s”服务帐户承担角色
创建备份作业的k8s服务帐户
使用backup ’ CR创建备份作业
S3安全配置
始终记住make TiDB backup S3 bucket private
为S3 bucket启用加密