kubernetes https双向认证-----ca认证
为什么写这个呢？ 在没有了解k8s认证的时候干过一件蠢事，公司项目是通过bearer
token进行权限认证的，当时一直在纠结这个token是哪儿来的，然后各种查询secret对比是否一样，最后找到了一个，那个时候并不知道这个token是如何认证的，如何拥有资源的操作权限的，就跑到一个qq群里面去问了一个问题，
感觉自己跟个傻子一样。
这个问题当时并没有去深究，后面不知道干什么事把这个给忘了，前几天想起来又开始搜博客开始学习。
大致的流程，不管通过ca认证还是token认证。都会获取ca证书或者token里面的cn 用户名 或者 o 组信息,通过用户名或者组信息进行查询对应的角色信息。
k8s权限认证过程，这里主要讲的是k8s认证（Authentication）
认证方式有哪些
X509 Client Certs
这是就是这篇文章讲述的重点，https双向认证
Static Token File
静态token列表文件，需要预先在 API Server 服务器上放置该文件，并且在api server的启动参数中加上–token-auth-file=SOMEFILE,token文件为csv格式，应至少包含token, user name, user uid这三个字段(逗号分隔)以及一个可选的group names字段
password,user,uid,“group1,group2,group3”
注意如果用户组有多个的话，整个用户组需要用双引号括起来。
Bootstrap Tokens
Static Password File
跟静态 Token 文件类似，只是使用了用户名密码的形式进行认证，使用的是http basic auth类型的认证方式，启动参数为–basic-auth-file=SOMEFILE，文件格式为：
password,user,uid,“group1,group2,group3”
Service Account Tokens
k8s内部用户体系 Service Account 使用的 Token，认证方式也是bearer token。api-server本身不关注流量是从哪里过来的，所以基于service account创建的token，只要你拿到了这个token，是可以从集群外部发起请求的，api-server会将此请求认证为对应的service account用户。
service account资源文件中挂载了secret，token字段即为我们需要的令牌（jwt格式），拿着这个令牌就可以直接发起请求了。 注意在secret中保存的token是经过base64编码的，实际使用时还需要先进行base64解码操作。
获取service account资源，并获取其中一个service account的yaml文件，里面有一个属性secrets，这个secret资源里面保存的访问api service需要的token（即为我们需要的令牌（jwt格式）） 主要用于认证使用。
[root@master ~]# kubectl get sa
NAME SECRETS AGE
default 1 194d
foo 1 41d
kubeapps-operator 1 118d
nginx-ingress-1585530211 1 106d
nginx-ingress-1585530211-backend 1 106d
[root@master ~]# kubectl get sa default -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:creationTimestamp: "2020-01-02T01:26:56Z"name: defaultnamespace: defaultresourceVersion: "366"selfLink: /api/v1/namespaces/default/serviceaccounts/defaultuid: 2257a9d7-9b2c-4fca-ad82-bc6df6fa6d28
secrets:
- name: default-token-gkzck
[root@master ~]# kubectl get secret default-token-gkzck -o yaml
apiVersion: v1
data:ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01ERXdNakF4TWpZeE1sb1hEVEk1TVRJek1EQXhNall4TWxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBS1ByCllzUmsvUGR0WmU2Y253QzF2WkpGWEt3RW1ieHMyYVU5MmtpbjJ5N2czeE1JWmswcldobDdwOWVEUmg4QlJVb0gKNVl4RXk1QkRaTGFnT1ZkSnNOMVBQdEpWdFcvM0hOQkl4TWVEM3dVS0hObmVGN3NwUWNNbWFRbEVEd0FwK2NReAo1MzVIUzZhZ3F3RTFUZG9vcHgyZmw2bTluaDdKbXM1NHpHczlWNW5ESjQ5WUJLamY4dDJGdnBqcm1abHppUDdQCjY0YWw4dkJkcEhZMXgvZDhlNmV0YWFQdWxCSEt0emY4UEFjNDZYM2xoRTBVVEp4M2ZWb3BqeDB1aGRHTUU4Q3YKY25seWQ5NFpYb3p3VEN4SFJaQkNYdzlVbnNaWUw0ZVRzWjJQRVhIbk9RZ3VPNXVPeTNqVUNLWVlmbVhCa0hwUApJUy9CMmJxYTI4MXZFTlRsV0U4Q0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFHRXFjUy82VFlNQmpnd0dxZHdwYXNmcDROTngKRXNSVVkwK01GMHFROHMyYVpRRE5sUTRySFFRcUp1YWhoc043NS9jYjRsSFVNVEl0STBzWml3VENDM1Zha3N2SgpDakZ6elhiVDJpdWluZUZpOU9vK2o1UXdBOGlETU9Jbit4REZ6aW81RU1pcUxUcTVQOSs5QW5hY0h0aUdIRlBmCnNFcWV2amFiNllFMXRVNTNBTC9pVjI4WlZMems4dyt3M1F4MXpCWHdoRmNvQVJPeFhPeUxjbGxkbXcrdHNvTE8KR2hOMzhvSmc5K3FxMzJzeHk3TXlkUUcyZDYwSldjTEJNc3dIdWd2MHZzVFIzZmpGNW0vNmVpc2dsWkswUHB0NgpWQXZYZFA3NGp0OVFmMXE5TVB6d0J0UmNmdVA5QU9JV2NUYm10NUVLRjBzTWI4aGR4M2oyV0J5aG54cz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=namespace: ZGVmYXVsdA==token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltZ3RSVnBTVjJ3eE5GTlpSMmR6UlZwcmVtcFZjR3RRUW1OMmEyOUpkMlJITFZaMlh6bERaSHAyWjBFaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dFoydDZZMnNpTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJakl5TlRkaE9XUTNMVGxpTW1NdE5HWmpZUzFoWkRneUxXSmpObVJtTm1aaE5tUXlPQ0lzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEudnhMYjh1RWdmeTJ2ZXpmU1NQNDdfMzREdDlXTWZIQ2dRUTVUSnZPcEh1LTd3SjE4WmNCbHRUTzg0eFJRWVdsZmI1VGVCdmVlMXkta0tWV3FocGpuV2lQalczZFNoaFdtLXdFYThvOEUtSHEyTU92TVlsakVENVk1ZnFWU2NwckU1eFJ4bm0wV29sV3RGZHhlZmZRX2ZvbEV5cTBVOTRJemE3Z0hUTkFnOTQ1V0RiZ05MTjFtN1IyNHljZzUyVFZRZ1NxaEZLeUdyc3R3U3ZhdUZaZjZqelBFbVI3M2xDb1hTR1VJNWVXNG13OV95R2doMDVVU2w0bUF3dU0yVk9sRnJFVGt2dDJ1QUs5LUZsTFhGQkpKMml6WTAyWXhhZkJoX1JhNGlaaUtvY1YxREVOWWZIaHNySm5NZE5EWWJzTXhhcVduckRfam1EcjRZQUExMHIwd2RR
kind: Secret
metadata:annotations:kubernetes.io/service-account.name: defaultkubernetes.io/service-account.uid: 2257a9d7-9b2c-4fca-ad82-bc6df6fa6d28creationTimestamp: "2020-01-02T01:26:56Z"name: default-token-gkzcknamespace: defaultresourceVersion: "363"selfLink: /api/v1/namespaces/default/secrets/default-token-gkzckuid: ce565b63-465b-48de-99b2-3ec493de155b
type: kubernetes.io/service-account-token
这个文件字段是通过base64加密后得到都得值，首先我们解密token
"eyJhbGciOiJSUzI1NiIsImtpZCI6ImgtRVpSV2wxNFNZR2dzRVprempVcGtQQmN2a29Jd2RHLVZ2XzlDZHp2Z0EifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZWZhdWx0Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImRlZmF1bHQtdG9rZW4tZ2t6Y2siLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZGVmYXVsdCIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjIyNTdhOWQ3LTliMmMtNGZjYS1hZDgyLWJjNmRmNmZhNmQyOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZWZhdWx0OmRlZmF1bHQifQ.vxLb8uEgfy2vezfSSP47_34Dt9WMfHCgQQ5TJvOpHu-7wJ18ZcBltTO84xRQYWlfb5TeBvee1y-kKVWqhpjnWiPjW3dShhWm-wEa8o8E-Hq2MOvMYljED5Y5fqVScprE5xRxnm0WolWtFdxeffQ_folEyq0U94Iza7gHTNAg945WDbgNLN1m7R24ycg52TVQgSqhFKyGrstwSvauFZf6jzPEmR73lCoXSGUI5eW4mw9_yGgh05USl4mAwuM2VOlFrETkvt2uAK9-FlLXFBJJ2izY02YxafBh_Ra4iZiKocV1DENYfHhsrJnMdNDYbsMxaqWnrD_jmDr4YAA10r0wdQ"
jwt事三段式的，头部（header ），载荷（payload ），签名 （signature）,解析载荷
{
"iss":"kubernetes/serviceaccount",
"kubernetes.io/serviceaccount/namespace":"default",
"kubernetes.io/serviceaccount/secret.name":"default-token-gkzck",
"kubernetes.io/serviceaccount/service-account.name":"default",
"kubernetes.io/serviceaccount/service-account.uid":"2257a9d7-9b2c-4fca-ad82-bc6df6fa6d28",
"sub":"system:serviceaccount:default:default"
}
下面主要介绍的是https双向认证
k8s已经拥有了根证书，所以我们无需生成根证书。直接使用k8s默认的根证书即可
1、证书的生成
这儿我使用的工具是openssl
1、生成私钥
2、生成csr文件
[root@master ~]# mkdir testca
[root@master ~]# cd testca/
[root@master testca]# openssl genrsa -out test.key 2048
Generating RSA private key, 2048 bit long modulus
.......+++
..................+++
e is 65537 (0x10001)
[root@master testca]# ls
test.key
[root@master testca]# openssl req -new -key test.key -out test.csr -subj "/CN=test"
[root@master testca]# ls
test.csr test.key
[root@master testca]#
3、通过csr文件生成证书，这里又两种方式
一、通过/etc/kubernetes/pki/ca.crt 和 /etc/kubernetes/pki/ca.key 颁发证书
[root@master testca]# openssl x509 -req -in test.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out test.crt -days 365
Signature ok
subject=/CN=test
Getting CA Private Key
[root@master testca]# ^C
[root@master testca]# ls
test.crt test.csr test.key
[root@master testca]#
二、通过创建k8s内置资源CertificateSigningRequest颁发证书 k8s提供了证书签发分api
cat test.csr | base64 | tr -d '\n' 将test.csr文件通过base64加密
将得到的base64编码拷贝到test-csr.yaml的request文件中
通过kubectl apply -f test-csr.yaml创建CertificateSigningRequest资源
[root@master testca]# ls
test.crt test.csr test.key
[root@master testca]# cat test.csr | base64 | tr -d '\n'
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZEQ0NBVHdDQVFBd0R6RU5NQXNHQTFVRUF3d0VkR1Z6ZERDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRApnZ0VQQURDQ0FRb0NnZ0VCQUtGN0dhb3lRTXlYbmRvcFd4NEt5cVdPalRjZDR5U1haQjlUM3R0eVU0QWxReFltCjc1WDRxTXpRbkc1ZDZwNzBlU0xOMjlJZHBMU1BHUzViQnNCTEIvencvOGlVdUJOa0RRYmR5Uk9VbUZpemhHSi8KQ0VDZktEQVlubWJJa2RwVVN0SDRQNzNEZTAwT1NVMk5wdGtld0pLNnBOTFM0N1JpUVVKbWozNitFdFlQRHZ5OQpzenRqeDZlcTVxd3B1SzZPZlNsS0h2NHNMaVFDL2l4RXBySjBMeEFBTHA4MEtYSXpJNlpScVhFYldkOUJyVGROClNwOVZ3THZzYzhpcE9mVFh3UFE4QjdCZUdlYjZUMlVFZ29yWW5EcENQWHRFTTY1Mzk0blRTc09sZWdSRkxZczcKT3NKU3hFbEhweldZaDUyUkxLUk5nVUc2bmVzY1I1WUZseGcvS1lVQ0F3RUFBYUFBTUEwR0NTcUdTSWIzRFFFQgpDd1VBQTRJQkFRQXk0bHZCK2owTFJmSmZjY01uakFyK2c4R0oxMGFjMk1acWw2L3dEWnZ3OHpXazNGZmJ4YUI2CjRzK1Y5WVNrRWxwa2RVWEJDTVFSUWZuVWVRTy9oQzdDWXBXWHF5V0I4Y0lCWFBFV09VbG5SZzRGaFJadUg1TXoKMWJYcko0bGJwQjQ0dmEyZEhKamswRFh4b2JESlUxTENxaGdtc2pMcVdtSlFtNVhUNTlHdGZRaU5TSmhMTWNGRAo1V2FOR2FoNXNPc0RZQVd6T2JrMzBhTXlhOE8rN0UyT21Obk15Z0VtbkVDMC9oOXJHL2NmcnJvOW1vRWRKaDlaCnYxL0tlYWIxVk42SnZWaVpMcFd3cXpsZzNqREV6bXdKSU53aUFkY2xDZVl3TmdvY0I4QmRBenREYXpHdFJ3RkwKSXh3QWViYkFKMEdPVGxXV2lwNU40SUkyQU9yMXQ5L0cKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==[root@master testca]#
[root@master testca]# vi test-csr.yaml
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:name: test-csr
spec:request: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURSBSRVFVRVNULS0tLS0KTUlJQ1ZEQ0NBVHdDQVFBd0R6RU5NQXNHQTFVRUF3d0VkR1Z6ZERDQ0FTSXdEUVlK
S29aSWh2Y05BUUVCQlFBRApnZ0VQQURDQ0FRb0NnZ0VCQUtGN0dhb3lRTXlYbmRvcFd4NEt5cVdPalRjZDR5U1haQjlUM3R0eVU0QWxReFltCjc1WDRxTXpRbkc
1ZDZwNzBlU0xOMjlJZHBMU1BHUzViQnNCTEIvencvOGlVdUJOa0RRYmR5Uk9VbUZpemhHSi8KQ0VDZktEQVlubWJJa2RwVVN0SDRQNzNEZTAwT1NVMk5wdGtld0
pLNnBOTFM0N1JpUVVKbWozNitFdFlQRHZ5OQpzenRqeDZlcTVxd3B1SzZPZlNsS0h2NHNMaVFDL2l4RXBySjBMeEFBTHA4MEtYSXpJNlpScVhFYldkOUJyVGROC
lNwOVZ3THZzYzhpcE9mVFh3UFE4QjdCZUdlYjZUMlVFZ29yWW5EcENQWHRFTTY1Mzk0blRTc09sZWdSRkxZczcKT3NKU3hFbEhweldZaDUyUkxLUk5nVUc2bmVz
Y1I1WUZseGcvS1lVQ0F3RUFBYUFBTUEwR0NTcUdTSWIzRFFFQgpDd1VBQTRJQkFRQXk0bHZCK2owTFJmSmZjY01uakFyK2c4R0oxMGFjMk1acWw2L3dEWnZ3OHp
XazNGZmJ4YUI2CjRzK1Y5WVNrRWxwa2RVWEJDTVFSUWZuVWVRTy9oQzdDWXBXWHF5V0I4Y0lCWFBFV09VbG5SZzRGaFJadUg1TXoKMWJYcko0bGJwQjQ0dmEyZE
hKamswRFh4b2JESlUxTENxaGdtc2pMcVdtSlFtNVhUNTlHdGZRaU5TSmhMTWNGRAo1V2FOR2FoNXNPc0RZQVd6T2JrMzBhTXlhOE8rN0UyT21Obk15Z0VtbkVDM
C9oOXJHL2NmcnJvOW1vRWRKaDlaCnYxL0tlYWIxVk42SnZWaVpMcFd3cXpsZzNqREV6bXdKSU53aUFkY2xDZVl3TmdvY0I4QmRBenREYXpHdFJ3RkwKSXh3QWVi
YkFKMEdPVGxXV2lwNU40SUkyQU9yMXQ5L0cKLS0tLS1FTkQgQ0VSVElGSUNBVEUgUkVRVUVTVC0tLS0tCg==usages:- digital signature- key encipherment- server auth
~
~
~
~
~
~
~
~
"test-csr.yaml" [New] 10L, 1366C written
[root@master testca]#
[root@master testca]#
[root@master testca]# ls
test.crt test.csr test-csr.yaml test.key
查看csr资源，可以看到其状态是pending状态
请注意，该请求仍处于待处理状态。集群管理员必须先批准它才能变为活动状态。
kubectl certificate approve test-csr 这条指令用于激活状态，可以通过kubectl get csr test-csr -o yaml 查看他的status.certificate字段中已经有相应证书的base64编码了
[root@master testca]# kubectl create -f test-csr.yaml
certificatesigningrequest.certificates.k8s.io/test-csr created
[root@master testca]# kubectl get csr
NAME AGE REQUESTOR CONDITION
test-csr 10s kubernetes-admin Pending
[root@master testca]# kubectl certificate approve test-csr
certificatesigningrequest.certificates.k8s.io/test-csr approved
[root@master testca]# kubectl get csr
NAME AGE REQUESTOR CONDITION
test-csr 44s kubernetes-admin Approved,Issued
将生成的证书保存到对应的crt文件中通过指令kubectl get csr test-csr -o jsonpath='{.status.certificate}' | base64 --decode > testapi.crt
[root@master testca]# kubectl get csr test-csr -o jsonpath='{.status.certificate}' | base64 --decode > testapi.crt
[root@master testca]# ls
testapi.crt test.crt test.csr test-csr.yaml test.key
这里如何验证我们生成的证书是否是有效的呢？
1、role rolebinding 或者是clusterrole clusterrolebinding创建角色并绑定用户
2、通过指令kubectl auth can-i get node --as test查看用户是否有操作某些资源的权限，如果返回yes则表示用户拥有该资源的权限，如果返回no 则表示没有改资源的操作权限
3、通过修改.kube/config文件，并切换context来验证是否拥有某些资源的操作权限
2、创建clusterrole以及clusterrolebinding资源，用于用户角色绑定
1、生成clusterrole资源的yaml文件
[root@master testca]# vi test-clusterrole.yaml
- apiGroups
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:name: test-clusterrole
rules:
- apiGroups:- ""resources:- podsverbs:- get- list- watch
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"test-clusterrole.yaml" 13L, 184C written
2、生成clusterrolebinding资源的yaml文件文件
[root@master testca]# vi test-clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: test-cluster-role-binding
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: test-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.iokind: Username: test
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
"test-clusterrolebinding.yaml" [New] 12L, 276C written
[root@master testca]# ls
3、创建yaml文件分别创建clusterRole和ClusterRoleBinding资源
[root@master testca]# kubectl create -f test-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/test-clusterrole created
[root@master testca]# kubectl create -f test-clusterrolebinding.yaml
clusterrolebinding.rbac.authorization.k8s.io/test-cluster-role-binding created
3、验证证书是否有效
通过kubectl auth can-i get node --as test 查看用户分配的角色是否有效了 这里的test表示的是用户名
yes表示有操作权限
no表示没有操作权限
[root@master testca]# kubectl auth can-i get node --as test
Warning: resource 'nodes' is not namespace scoped
no
[root@master testca]# kubectl auth can-i get pods --as test
yes
[root@master testca]# kubectl auth can-i get node
Warning: resource 'nodes' is not namespace scoped
yes
[root@master testca]#
如何验证证书是否生效，我们通过kubectl 的配置文件来
个人认为 kubectl 客户端与k8s apiserver交互时是使用的./kube/config中的证书进行权限认证的，所以我们可以通过向/kube/config 添加user以及相关的证书和context 操作如下
1、查看kubectl config的配置文件 通过指令kubectl config view
这里面的bob可以忽略不记，这个是以前实验的时候加进去的
[root@master testca]# kubectl config view
apiVersion: v1
clusters:
- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.56.101:6443name: kubernetes
contexts:
- context:cluster: kubernetesuser: bobname: bob@kubernetes
- context:cluster: kubernetesuser: kubernetes-adminname: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: bobuser:client-certificate-data: REDACTEDclient-key-data: REDACTED
- name: kubernetes-adminuser:client-certificate-data: REDACTEDclient-key-data: REDACTED
[root@master testca]#
2、向config中添加user信息 通过指令kubectl config set-credentials test --client-certificate=./test.crt --client-key=./test.key --embed-certs=true
[root@master testca]# ls
testapi.crt test-clusterrolebinding.yaml test.crt test-csr.yaml
test-clusterrole test-clusterrole.yaml test.csr test.key
[root@master testca]# kubectl config set-credentials test --client-certificate=./test.crt --client-key=./test.key --embed-certs=true
User "test" set.
[root@master testca]# kubectl config view
apiVersion: v1
clusters:
- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.56.101:6443name: kubernetes
contexts:
- context:cluster: kubernetesuser: bobname: bob@kubernetes
- context:cluster: kubernetesuser: kubernetes-adminname: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: bobuser:client-certificate-data: REDACTEDclient-key-data: REDACTED
- name: kubernetes-adminuser:client-certificate-data: REDACTEDclient-key-data: REDACTED
- name: testuser:client-certificate-data: REDACTEDclient-key-data: REDACTED
[root@master testca]#
3、向config里面添加context信息 kubectl config set-context test@kubernetes --cluster=kubernetes --user=test
[root@master testca]# kubectl config set-context test@kubernetes --cluster=kubernetes --user=test
Context "test@kubernetes" created.
[root@master testca]#
...
contexts:
- context:cluster: kubernetesuser: bobname: bob@kubernetes
- context:cluster: kubernetesuser: kubernetes-adminname: kubernetes-admin@kubernetes
- context:cluster: kubernetesuser: testname: test@kubernetes
...
4、 使用test用户的证书与k8sapi交互，用户切换指令 kubectl config use-context test@kubernetes
[root@master testca]# kubectl config use-context test@kubernetes
Switched to context "test@kubernetes".
[root@master testca]# kubectl get pods
NAME READY STATUS RESTARTS AGE
kubia-website-6cf9b5b5fc-2bj97 0/1 Evicted 0 14d
kubia-website-6cf9b5b5fc-2xttd 0/1 Evicted 0 13d
[root@master testca]# kubectl get node
Error from server (Forbidden): nodes is forbidden: User "test" cannot list resource "nodes" in API group "" at the cluster scope
因为test用户我们只配置了pods的get list watch权限，所以没有其他资源的权限，所以获取node资源失败
这个只是做校验看证书是否生效，现在我们将context切换回去
[root@master testca]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
ca证书的认证大概就是这个流程。
这里面可能设计到很多的概念，对称加密，非对称加密，数字签名等等，这个有兴趣大家可以去了解一下
这里面通过CertificateSigningRequest签发的证书有问题，认证通不过，后面查到原因在分享
kubernetes https双向认证-----ca认证相关推荐
- tcp3次握手，https加密，ca认证
参考: https://baijiahao.baidu.com/s?id=1570143475599137&wfr=spider&for=pc 转载于:https://www.cnbl ...
- CA认证（Certificate Authority）
什么是CA认证? CA认证,即电子认证服务是指为电子签名相关各方提供真实性.可靠性验证的活动.证书颁发机构(CA, Certificate Authority)即颁发数字证书的机构.是负责发放和管理数 ...
- 用pfx证书java双向认证_把CA证书生成的crt的证书和pem的私钥转换成java能够使用的keystore和pcks12的证书，实现https双向认证...
最近在做一个https双向认证的工作,领导先让我实现,我之前写了一篇文章,把tomcat的生成证书和配置的实现写了出来. 现在领导给了我服务器的CA证书的客户端证书和私钥,服务端信任证书,分别是crt ...
- 证书类型、自签CA证书、https双向认证（一篇就懂系列）
#博学谷IT学习技术支持# 文章目录 1.Linux准备环境 2.证书扩展名 3.自签CA证书 3.1 生成根证书 3.2 生成服务端证书 3.3 生成客户端证书 4.开启https,并校验客户端(双 ...
- Apache httpd设置HTTPS双向认证
一.环境 httpd: 2.4.4 openssl:1.0.1 os:ubuntu 12.04 LTS 二.场景 我准备在httpd上配置一个HTTPS双向认证,既向客户端表明自己的身份,也只允许 ...
- httpd设置HTTPS双向认证
去年用tomcat.jboss配置过HTTPS双向认证,那时候主要用的是JDK自带的keytool工具.这次是用httpd + openssl,区别比较大 在网上搜索了很多文章,发现全面介绍的不多,或 ...
- android 客户端bks,Keytools Https双向认证（Android通用）
Https认证: 单向认证:保证服务器是可信任的,可以安全的访问的! 客户端拿到服务器的证书,通过CA认证信任,然后取出公钥,加密对称密钥传给服务器,服务器用自己的私钥解密得到对称密钥,后续使用该对称 ...
- 巧用 Nginx 快速实现 HTTPS 双向认证
1.原理 双向认证,顾名思义,客户端和服务器端都需要验证对方的身份,在建立 HTTPS 连接的过程中,握手的流程比单向认证多了几步.单向认证的过程,客户端从服务器端下载服务器端公钥证书进行验证,然后建 ...
- HTTPS双向认证（Mutual TLS authentication)
HTTPS双向认证(Mutual TLS authentication) 双向认证,顾名思义,客户端和服务器端都需要验证对方的身份,在建立Https连接的过程中,握手的流程比单向认证多了几步.单向认证 ...
最新文章
- 学习笔记-express路径问题
- 小米资深工程师瞿晋萍（男）：米聊服务器的技术选型和架构设计
- HALCON选择标定板文件
- linux lite 安装步骤,Linux Lite第一个支持Linux 4.14及如何安装
- Ubuntu16.04安装NVIDIA显卡（RTX20系列）驱动+CUDA10.0+cudnn+Pytorch1.1.0
- 语言时间序列年月日_R语言系列 时间序列分析
- Java：银行账户类
- Quartus 使用tcl分配管脚
- anaconda moviepy_Win10配置anaconda和jupyter
- Android开发相关操作
- android-Vibrator的使用
- php 的sentmail支持ssl吗_php 的swoole 和websocket 连接wss
- 关于假人皮肤外侧热传导问题的差分法求解
- Android数据加密之——Base64编码算法
- NLP︱中文分词技术小结、几大分词引擎的介绍与比较
- Keras中verbose的作用
- 排球分组循环交叉编排_全国气排球邀请赛在我市举行
- 小程序源码：未来老婆查询生成器-多玩法安装简单
- 最后一本书 第六章课后练习3，4
- 【转】Guide to Elliptic Curve Cryptography（ECC椭圆曲线算法1）