x509证书信息说明
以下是kube-apiserver的证书示例
Certificate:
Data:
Version: 3 (0x2) # 版本号
Serial Number: 12 (0xc) # 序列号 对于所有的版本,同一个CA颁发的证书序列号都必须是唯一的。
Signature Algorithm: sha256WithRSAEncryption # ID签名算法
Issuer: C = BJ, O = Tech, OU = SRE, CN = www.ca.com # 颁发者名称
Validity # 有效期
Not Before: Aug 14 10:01:46 2022 GMT
Not After : Aug 11 10:01:46 2032 GMT
Subject: C = BJ, ST = BJ, L = BJ, O = Tech, OU = SRE, CN = system:api-server
Subject Public Key Info: # 主题公钥信息
Public Key Algorithm: rsaEncryption # 公钥算法
RSA Public-Key: (2048 bit) # 公钥
Modulus:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
DirName:/C=BJ/O=Tech/OU=SRE/CN=www.ca.com
serial:BB:A3:04:8F:CF:8C:F8:99
X509v3 Basic Constraints: # 用于指示一份证书是不是CA证书。
CA:FALSE
X509v3 Key Usage: # 指定了这份证书包含的公钥可以执行的密码操作
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage: # 典型用法是指定叶子证书中的公钥的使用目的。它包括一系列的OID,每一个都指定一种用途
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Subject Alternative Name: # 描述可以使用的主机名,IP地址等
DNS:www.kubernetes.com, DNS:master01.kubernetes.com, DNS:master02.kubernetes.com, IP Address:172.20.0.1 # 除了apiserver向外部暴露的域名,apiserver在集群内部对应的service ip,与需要加到这里
Signature Algorithm: sha256WithRSAEncryption # 证书签名算法
kube-apiserver 证书相关配置
--etcd-certfile string
--cert-dir string
--tls-cert-file string
--tls-private-key-file string
--tls-sni-cert-key namedCertKey
--client-ca-file string
--oidc-ca-file string
--requestheader-allowed-names strings
--requestheader-client-ca-file string
--kubelet-certificate-authority string
--kubelet-client-certificate string
--proxy-client-cert-file string
--proxy-client-key-file string
对应以下几种需要证书通信的配置
- client(kubectl,restapi等):普通用户作为client与apiserver之间的通信,对各类资源进行操作
- apiserver本身是一个http服务器,需要tls证书,对应以下两个配置
- –tls-cert-file
- –tls-private-key-file
- apiserver也需要对client进行验证,但是client过多,因此需要统一的ca签发client证书
- –client-ca-file
- 除此以外,apiserver需要通过证书确认client的身份,通过CN和O来识别用户,开启RBAC的用户要配置CN和O做一些授权
- CN:Common Name,kube-apiserver 从证书中提取作为请求的用户名 (User Name);浏览器使用该字段验证网站是否合法;
- O:Organization,kube-apiserver 从证书中提取该字段作为请求用户所属的组 (Group)
- kubelet,kubeproxy:master与node之间的通信,存在两种模式,1是kubelet,kubeproxy作为client,去访问apiserver,2是apiserver作为client,去访问1是kubelet
- kubelet,kubeproxy作为client,去访问apiserver(与上述client 访问模式类似)
- apiserver作为client,去访问kubelet的相关配置
- –kubelet-client-certificate apiserver 作为client的证书
- –kubelet-client-key apiserver 作为client的证书密钥
- –kubelet-preferred-address-types
- –kubelet-certificate-authority kubelet server证书的ca
- kubelet 作为server的证书配置(以下3个命令行配置在后续版本会挪到–config指定的配置文件中),
- –tls-cert-file kubelet 作为server的证书(在实际的部署过程中,该证书不建议手动生成,由集群统一签发,签发到–cert-dir= 参数指定的路径)
- –tls-private-key-file kubelet 作为server的证书密钥
- –client-ca-file
- apiserver本身是一个http服务器,需要tls证书,对应以下两个配置
- etcd:k8s的存储库,主要是apiserver作为client,去访问etcd server
- apiserver作为client的配置
- –etcd-cafile etcd server证书的ca
- –etcd-certfile etcd server的证书
- –etcd-keyfile etcd server证书的密钥
- etcd 作为server的相关配置
- –cert-file etcd 作为server的证书
- –key-file etcd 作为server的证书密钥
- apiserver作为client的配置
- webhook:这里指apiserver提供的admission-webhook,在数据持久化前调用webhook
- aggregation layer:扩展apiserver, 需要将自定义的api注册到k8s中,相比CRD灵活性更高,(Aggregated APIServer与CRD区别请参考官方文档)
- aggregation 访问流程
- pod: 在pod中调用apiserver (在pod中通过serviceacount认证,pod需要认证apiserver的证书,其他几种需要client和server双向认证。)
- serviecaccount同样在apiserver有两个证书配置
- –service-account-key-file (service account issue的公钥,用于验证service account)
- –service-account-signing-key-file (service-account-key-file 对应的密钥)
- 对应controller也有一个配置项
- –service-account-private-key-file (service-account-key-file 对应的密钥,与apiserver –service-account-signing-key-file 配置相同的密钥文件,用来实际签署service account tokens)
- serviecaccount同样在apiserver有两个证书配置