2、k8s api访问-token、RBAC、证书

1、token方式使用k8s restful api思维导图

https://liumiaocn.blog.csdn.net/article/details/100518110

token方式使用k8s restful api思维导图

2、apiserver认证

2.1、Kubernetes apiserver认证

Kubernetes apiserver认证

apiserver的认证方式思维导图

K8S Api Server认证

目录

• 认证类型
• 基于CA证书的双向认证
  • apiserver端配置
  • 生成客户端私钥和证书
  • master核心组件与apiserver的认证方式
• HTTP Token认证
• HTTP Basic认证
• kubectl config简要说明

https://kubernetes.io/docs/reference/access-authn-authz/authentication/

2.2、生成证书

 server端

使用OpenSSL生成一个CA根证书，并用这个根证书颁发server和client子证书

公钥/私钥/签名/验证签名/加密/解密/非对称加密

 

　　对称加密，用一个密码加密，用同样的密码解密；非对称加密：用一个密码加密，用另外一组密码。这是数学上的一个素数积求因子的原理的应用；公钥和私钥：字证书采用公钥体制，用一对互相匹配的密钥进行加密、解密。用户自己设定一把特定的仅为本人所知的私有密钥（私钥），用它进行解密和签名，同时设定一把公共密钥（公钥）并由本人公开，为一组用户所共享，用于加密和验证签名。

 

RSA/DSA/SHA/MD5

　　非对称加密的算法有很多，比较著名的有RSA/DSA ，RSA可以用于加/解密，也可以用于签名验签，DSA只能用于签名。

　　SHA是一种和MD5相同的算法，它不是用于加密解密或者签名的，它被称为摘要算法。就是通过一种算法，依据数据内容生成一种固定长度的摘要，这串摘要值与原数据存在对应关系，就是原数据会生成这个摘要，但是这个摘要是不能还原成原数据。这个算法起的作用就是，如果你修改原数据，那么生成的摘要会不同，传输过程中把原数据给你再给你一个摘要，你把得到的原数据同样做一次摘要算法，与给你的摘要相比较就可以知道这个数据有没有在传输过程中被修改了。

　　实际应用过程中，因为需要加密的数据可能会很大，进行加密费时费力，所以一般都会把原数据先进行摘要，然后对这个摘要值进行加密，将原数据的明文和加密后的摘要值一起传给你，这样你解开加密后的摘要值，再和你得到的数据进行的摘要值对应一下就可以知道数据有没有被修改了，因为私钥只有你有，只有你能解密摘要值，所以别人就算把原数据做了修改，然后生成一个假的摘要给你也是不行的，你这边用密钥也解不开。

 

CA/PEM/DER/X509/PKCS

　　一般的公钥不会用明文传输给别人的，正常情况下都会生成一个文件，这个文件就是公钥文件，然后这个文件可以交给其他人用于加密，但是传输过程中如果有人恶意破坏，将你的公钥换成了他的公钥，然后得到公钥的一方加密数据，他就可以用他自己的密钥解密看到数据了，为了解决这个问题，需要一个公证方来做这个事，任何人都可以找它来确认公钥是谁发的。这就是CA，CA确认公钥的原理也很简单，它将它自己的公钥发布给所有人，然后一个想要发布自己公钥的人可以将自己的公钥和一些身份信息发给CA，CA用自己的密钥进行加密，这里也可以称为签名。然后这个包含了你的公钥和你的信息的文件就可以称为证书文件了。这样一来所有得到一些公钥文件的人，通过CA的公钥解密了文件，如果正常解密那么机密后里面的信息一定是真的，因为加密方只可能是CA，其他人没它的密钥。这样你解开公钥文件，看看里面的信息就知道这个是不是那个你需要用来加密的公钥了。

　　实际应用中，一般人都不会找CA去签名，因为那是收钱的，所以可以自己做一个自签名的证书文件，就是自己生成一对密钥，然后再用自己生成的另外一对密钥对这对密钥进行签名，这个只用于真正需要签名证书的人，普通的加密解密数据，直接用公钥和私钥来做就可以了。

　　密钥文件的格式用OpenSSL生成的就只有PEM和DER两种格式，PEM的是将密钥用base64编码表示出来的，直接打开你能看到一串的英文字母，DER格式是二进制的密钥文件。X509是通用的证书文件格式定义。PKCS的一系列标准是指定的存放密钥的文件标准，PEM、DER、X509、PKCS这几种格式可以互相转化.

 

k8s自签TLS证书

client端：

新版本的kubernetes中，已经不再需要手动为客户端生成证书。直接由Master端签发即可。

3、生成etcd证书

 

4、HTTPS方式ETCD客户端连接提示bad certificate对应方法

原因

证书设定问题，需检查证书生成时csr文件中是否正确设定，IP是否设定到hosts中

5、

Authenticating Proxy

The API server can be configured to identify users from request header values, such as X-Remote-User. It is designed for use in combination with an authenticating proxy, which sets the request header value.

可以将API服务器配置为从请求标头值识别用户，例如X-Remote-User。它设计用于与身份验证代理结合使用，后者可设置请求标头值

• --requestheader-username-headers Required, case-insensitive. Header names to check, in order, for the user identity. The first header containing a value is used as the username.
• --requestheader-group-headers 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names.
• --requestheader-extra-headers-prefix 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed. The remainder of the header name is lowercased and percent-decoded and becomes the extra key, and the header value is the extra value.

Note: Prior to 1.11.3 (and 1.10.7, 1.9.11), the extra key could only contain characters which were legal in HTTP header labels.

For example, with this configuration:

--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-

this request:

GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Acme.com%2Fproject: some-project
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile

would result in this user info:

name:fido

groups:- dogs- dachshundsextra:acme.com/project:- some-projectscopes:- openid- profile

In order to prevent header spoofing, the authenticating proxy is required to present a valid client certificate to the API server for validation against the specified CA before the request headers are checked. WARNING: do not reuse a CA that is used in a different context unless you understand the risks and the mechanisms to protect the CA's usage.

为了防止标头欺骗，在检查请求标头之前，身份验证代理需要向API服务器提供有效的客户端证书，以便根据指定的CA进行验证。警告：除非您了解保护CA使用的风险和机制，否则不要重用在不同上下文中使用的CA

• --requestheader-client-ca-file Required. PEM-encoded certificate bundle. A valid client certificate must be presented and validated against the certificate authorities in the specified file before the request headers are checked for user names 在检查请求头的用户名之前，必须提供有效的客户端证书，并根据指定文件中的证书颁发机构进行验证。
• --requestheader-allowed-names Optional. List of Common Name values (CNs). If set, a valid client certificate with a CN in the specified list must be presented before the request headers are checked for user names. If empty, any CN is allowed.

           通用名称值（CN）的列表。如果已设置，则必须提供有效的客户端证书（证书中的CN必须包含在--requestheader-allowed-names的值中），然后才能检查请求标头中的用户名。如果为空，则允许任何CN。

客户端证书常用名称列表。允许在--requestheader-username-headers指定的标头中提供用户名，如果为空，则允许在--requestheader-client-ca文件中通过当局验证的任何客户端证书

6、apiserver、etcd、controller-manager、scheduler启动参数

6.1、服务配置选项（kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy）

https://dongshao.blog.csdn.net/article/details/111771687

6.2、apiserver示例

 

官网翻译

Autenticating

k8s中的用户

 

 

 

 

 

 

 

 

 

 

 

htt

ps://www.yuque.com/docs/share/aafad058-2d1a-44f3-9577-478e189071b6?# 《token方式使用k8s restful api》https://www.yuque.com/docs/share/aafad058-2d1a-44f3-9577-478e189071b6?# 《token方式使用k8s restful api

https://www.yuque.com/docs/share/aafad058-2d1a-44f3-9577-478e189071b6?# 《token方式使用k8s restful api》

https://www.yuque.com/docs/share/aafad058-2d1a-44f3-9577-478e189071b6?# 《token方式使用k8s restful api》

https://www.yuque.com/docs/share/3c13d955-0e3d-4dcc-8fd8-f2f9c93a15b5?# 《api