authentication
weight: 89
title: Kubernetes 中的用户与身份认证授权
date: “2022-05-21T00:00:00+08:00”
type: book
在安装集群的时候我们在
重点查看
认识Kubernetes 中的用户
普通用户被假定为由外部独立服务管理。管理员分发私钥,用户存储(如
相对的,Secret
,这些凭证同时被挂载到
kubectl
的人类用户到节点上的 kubelet
,到控制平面的成员,都必须在向
认证策略
- 用户名:标识最终用户的字符串。常用值可能是
kube-admin
或jane@example.com
。 - UID:标识最终用户的字符串,比用户名更加一致且唯一。
- 组:一组将用户和常规用户组相关联的字符串。
- 额外字段:包含其他有用认证信息的字符串列表的映射。
所有的值对于认证系统都是不透明的,只有 授权人 才能解释这些值的重要含义。
您可以一次性启用多种身份验证方式。通常使用至少以下两种认证方式:
- 服务帐户的
service account token - 至少一种其他的用户认证的方式
当启用了多个认证模块时,第一个认证模块成功认证后将短路请求,不会进行第二个模块的认证。
system:authenticated
组包含在所有已验证用户的组列表中。
与其他身份验证协议(LDAP、SAML、Kerberos、
X509 客户端证书
通过将 --client-ca-file=SOMEFILE
选项传递给
例如,使用 openssl
命令工具生成用于签名认证请求的证书:
openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app2"
这将为一个用户名为 ”jbeda“ 的
静态Token 文件
当在命令行上指定 --token-auth-file=SOMEFILE
选项时,
token,user,uid,"group1,group2,group3"
在请求中放置Bearer Token
当使用来自Authorization
Bearer token
的值。31ada4fd-adec-460c-809a-9e56ceb75269
,那么它将出现在
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269
Bootstrap Token
该功能仍处于
为了简化新集群的初始化引导过程,kube-system
这些[a-z0-9]{6}.[a-z0-9]{16}
。第一部分是
Authorization: Bearer 781292.db7bc3a58fc5f07e
在--experimental-bootstrap-token-auth
标志以启用--controllers
标志启用--controllers=*,tokencleaner
。如果您使用它来引导集群, kubeadm
会为您完成。
认证者认证为 system:bootstrap:<Token ID>
。被包含在 system:bootstrappers
组中。命名和组是有意限制用户使用过去的kubeadm
使用)来制定适当的授权策略以支持引导集群。
有关kubeadm
管理这些令牌,请参阅 Bootstrap Token。
静态密码文件
通过将 --basic-auth-file=SOMEFILE
选项传递给
基本身份认证是一个
password,user,uid,"group1,group2,group3"
当使用来自 Authorization
Basic BASE64ENCODED(USER:PASSWORD)
的值。
Service Account Token
--service-account-key-file
一个包含签名bearer token 的PEM 编码文件。如果未指定,将使用API server 的TLS 私钥。--service-account-lookup
如果启用,从API 中删除掉的token 将被撤销。
ServiceAccount
注入控制器 关联到集群中运行的PodSpec
的 serviceAccountName
字段显式地与
注意: serviceAccountName
通常被省略,因为这会自动生成。
apiVersion: apps/v1beta2
kind: Deployment
metadata:
name: nginx-deployment
namespace: default
spec:
replicas: 3
template:
metadata:
# ...
spec:
containers:
- name: nginx
image: nginx:1.7.9
serviceAccountName: bob-the-bot
kubectl create serviceaccount (NAME)
命令。这将在当前的
$ kubectl create serviceaccount jenkins
serviceaccount "jenkins" created
$ kubectl get serviceaccounts jenkins -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
# ...
secrets:
- name: jenkins-token-1yvwg
创建出的
$ kubectl get secret jenkins-token-1yvwg -o yaml
apiVersion: v1
data:
ca.crt: (APISERVER'S CA BASE64 ENCODED)
namespace: ZGVmYXVsdA==
token: (BEARER TOKEN BASE64 ENCODED)
kind: Secret
metadata:
# ...
type: kubernetes.io/service-account-token
注意:所有值是基于
经过签名的
system:serviceaccount:(NAMESPACE):(SERVICEACCOUNT)
,被指定到组 system:serviceaccounts
和 system:serviceaccounts:(NAMESPACE)
。
注意:由于
OpenID Connect Token
OpenID Connect 是由
为了识别用户,认证者使用id_token
(而不是 access_token
)作为
- 登陆到您的身份提供商
- 您的身份提供商将为您提供一个
access_token
,一个id_token
和一个refresh_token
- 当使用
kubectl
时,使用--token
标志和id_token
,或者直接加入到您的kubeconfig
文件中 kubectl
在调用API server 时将id_token
置于HTTP header 中API server 将通过检查配置中指定的证书来确保JWT 签名有效- 检查以确保
id_token
没有过期 - 确保用户已授权
- 授权
API server 后向kubectl
kubectl
向用户提供反馈
由于所有需要验证您身份的数据都在 id_token
中,
Kubernetes 没有 ”web 接口“ 来出发验证进程。没有浏览器或界面来收集凭据,这就是为什么您需要首先认证您的身份提供商。id_token
无法撤销,就像一个证书,所以它应该是短暂的(只有几分钟) ,所以每隔几分钟就得到一个新的令牌是非常烦人的。- 没有使用
kubectl proxy
命令或注入id_token
的反向代理,无法简单地对Kubernetes dashboard 进行身份验证。
配置API Server
要启用该插件,需要在
参数 | 描述 | 示例 | 是否必需 |
---|---|---|---|
--oidc-issuer-url |
允许https:// 的方案。通常是提供商的 |
如果发现https://accounts.google.com/.well-known/openid-configuration ,值应该是https://accounts.google.com |
是 |
--oidc-client-id |
所有的 |
kubernetes | 是 |
--oidc-username-claim |
sub 是最终用户的唯一标识符。管理员可以选择其他声明,如 email 或 name ,具体取决于他们的提供者。不过,email 以外的其他声明将以发行者的 |
sub | 否 |
--oidc-groups-claim |
groups | 否 | |
--oidc-ca-file |
用来签名您的身份提供商的网络 |
/etc/kubernetes/ssl/kc-ca.pem |
否 |
如果为 --oidc-username-claim
选择了除 email
以外的其他声明,则该值将以 --oidc-issuer-url
作为前缀,以防止与现有system:users
)冲突。例如,如果提供商网址是 https://accounts.google.com,而用户名声明映射到 jane
,则插件会将用户身份验证为:
https://accounts.google.com#jane
重要的是,azp
(授权方)声明的提供者,这是允许一个客户端代表另一个客户端发放令牌的机制。
对于身份提供商能够适用于
- 支持
OpenID connect 发现;不必是全部。 - 使用非过时密码在
TLS 中运行 - 拥有
CA 签名证书(即使CA 不是商业CA 或自签名)
有关上述要求CA
,可以使用 CoreOS
团队的 这个脚本 创建一个简单的
针对特定系统的安装说明:
使用kubectl
选项1 - OIDC 身份验证器
第一个选项是使用 oidc
身份验证器。此身份验证程序将您的 id_token
、refresh_token
和您的client_secret
kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token ) \
--auth-provider-arg=extra-scopes=( comma separated list of scopes to add to "openid email profile", optional )
例如,在向身份提供者进行身份验证之后运行以下命令:
kubectl config set-credentials mmosley \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP \
--auth-provider-arg=client-id=kubernetes \
--auth-provider-arg=client-secret=1db158f6-177d-4d9c-8a8b-d36869918ec5 \
--auth-provider-arg=refresh-token=q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXqHega4GAXlF+ma+vmYpFcHe5eZR+slBFpZKtQA= \
--auth-provider-arg=idp-certificate-authority=/root/ca.pem \
--auth-provider-arg=extra-scopes=groups \
--auth-provider-arg=id-token=eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
将产生下面的配置:
users:
- name: mmosley
user:
auth-provider:
config:
client-id: kubernetes
client-secret: 1db158f6-177d-4d9c-8a8b-d36869918ec5
extra-scopes: groups
id-token: eyJraWQiOiJDTj1vaWRjaWRwLnRyZW1vbG8ubGFuLCBPVT1EZW1vLCBPPVRybWVvbG8gU2VjdXJpdHksIEw9QXJsaW5ndG9uLCBTVD1WaXJnaW5pYSwgQz1VUy1DTj1rdWJlLWNhLTEyMDIxNDc5MjEwMzYwNzMyMTUyIiwiYWxnIjoiUlMyNTYifQ.eyJpc3MiOiJodHRwczovL29pZGNpZHAudHJlbW9sby5sYW46ODQ0My9hdXRoL2lkcC9PaWRjSWRQIiwiYXVkIjoia3ViZXJuZXRlcyIsImV4cCI6MTQ4MzU0OTUxMSwianRpIjoiMm96US15TXdFcHV4WDlHZUhQdy1hZyIsImlhdCI6MTQ4MzU0OTQ1MSwibmJmIjoxNDgzNTQ5MzMxLCJzdWIiOiI0YWViMzdiYS1iNjQ1LTQ4ZmQtYWIzMC0xYTAxZWU0MWUyMTgifQ.w6p4J_6qQ1HzTG9nrEOrubxIMb9K5hzcMPxc9IxPx2K4xO9l-oFiUw93daH3m5pluP6K7eOE6txBuRVfEcpJSwlelsOsW8gb8VJcnzMS9EnZpeA0tW_p-mnkFc3VcfyXuhe5R3G7aa5d8uHv70yJ9Y3-UhjiN9EhpMdfPAoEB9fYKKkJRzF7utTTIPGrSaSU6d2pcpfYKaxIwePzEkT4DfcQthoZdy9ucNvvLoi1DIC-UocFD8HLs8LYKEqSxQvOcvnThbObJ9af71EwmuE21fO5KzMW20KtAeget1gnldOosPtz1G5EwvaQ401-RPQzPGMVBld0_zMCAwZttJ4knw
idp-certificate-authority: /root/ca.pem
idp-issuer-url: https://oidcidp.tremolo.lan:8443/auth/idp/OidcIdP
refresh-token: q1bKLFOyUiosTfawzA93TzZIDzH2TNa2SMm0zEiPKTUwME6BkEo6Sql5yUWVBSWpKUGphaWpxSVAfekBOZbBhaEW+VlFUeVRGcluyVF5JT4+haZmPsluFoFu5XkpXk5BXq
name: oidc
一旦您的 id_token
过期,kubectl
将使用 refresh_token
刷新 id_token
,然后在 kube/.config
文件的client_secret
中存储 id_token
的值和refresh_token
的新值。
选项2 - 使用 --token
选项
可以在 kubectl
命令的 --token
选项中传入id_token
到该选项中:
kubectl --token=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL21sYi50cmVtb2xvLmxhbjo4MDQzL2F1dGgvaWRwL29pZGMiLCJhdWQiOiJrdWJlcm5ldGVzIiwiZXhwIjoxNDc0NTk2NjY5LCJqdGkiOiI2RDUzNXoxUEpFNjJOR3QxaWVyYm9RIiwiaWF0IjoxNDc0NTk2MzY5LCJuYmYiOjE0NzQ1OTYyNDksInN1YiI6Im13aW5kdSIsInVzZXJfcm9sZSI6WyJ1c2VycyIsIm5ldy1uYW1lc3BhY2Utdmlld2VyIl0sImVtYWlsIjoibXdpbmR1QG5vbW9yZWplZGkuY29tIn0.f2As579n9VNoaKzoF-dOQGmXkFKf1FMyNV0-va_B63jn-_n9LGSCca_6IVMP8pO-Zb4KvRqGyTP0r3HkHxYy5c81AnIh8ijarruczl-TK_yF5akjSTHFZD-0gRzlevBDiH8Q79NAr-ky0P4iIXS8lY9Vnjch5MF74Zx0c3alKJHJUnnpjIACByfF2SCaYzbWFMUNat-K1PaUk5-ujMBG7yYnr95xD-63n8CO8teGUAAEMx6zRjzfhnhbzX-ajwZLGwGUBT4WqjMs70-6a7_8gZmLZb2az1cZynkFRj2BaCkVT3A2RrjeEwZEtGXlMqKJ1_I2ulrOVsYx01_yD35-rw get nodes
Webhook Token 认证
--authentication-token-webhook-config-file
是一个用来描述如何访问远程webhook 服务的kubeconfig 文件。--authentication-token-webhook-cache-ttl
缓存身份验证策略的时间。默认为两分钟。
配置文件使用 kubeconfig 文件格式。文件中的 ”user“ 指的是
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authn-service
cluster:
certificate-authority: /path/to/ca.pem # CA for verifying the remote service.
server: https://authn.example.com/authenticate # URL of remote service to query. Must use 'https'.
# users refers to the API server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authn-service
user: name-of-api-sever
name: webhook
当客户端尝试使用
请注意,authentication.k8s.io/v1beta1
--runtime config =authentication.k8s.io/v1beta1=true
The request body will be of the following format:
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"spec": {
"token": "(BEARERTOKEN)"
}
}
预计远程服务将填写请求的 status
字段以指示登录成功。响应主体的 spec
字段被忽略,可以省略。成功验证后的
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"status": {
"authenticated": true,
"user": {
"username": "janedoe@example.com",
"uid": "42",
"groups": ["developers", "qa"],
"extra": {
"extrafield1": ["extravalue1", "extravalue2"]
}
}
}
}
未成功的请求将返回:
{
"apiVersion": "authentication.k8s.io/v1beta1",
"kind": "TokenReview",
"status": {
"authenticated": false
}
}
认证代理
可以配置X-Remote-User
。这样的设计是用来与请求
--requestheader-username-headers
必需,大小写敏感。按header 名称和顺序检查用户标识。包含值的第一个header 将被作为用户名。--requestheader-group-headers
1.6 以上版本。可选。大小写敏感。建议为 “X-Remote-Group”。按header 名称和顺序检查用户组。所有指定的header 中的所有值都将作为组名。--requestheader-extra-headers-prefix
1.6 以上版本。可选,大小写敏感。建议为 “X-Remote-Extra-”。标题前缀可用于查找有关用户的额外信息(通常由配置的授权插件使用) 。以任何指定的前缀开头的header 都会删除前缀,header 名称的其余部分将成为额外的键值,而header 值则是额外的值。
例如下面的配置:
--requestheader-username-headers=X-Remote-User
--requestheader-group-headers=X-Remote-Group
--requestheader-extra-headers-prefix=X-Remote-Extra-
该请求:
GET / HTTP/1.1
X-Remote-User: fido
X-Remote-Group: dogs
X-Remote-Group: dachshunds
X-Remote-Extra-Scopes: openid
X-Remote-Extra-Scopes: profile
将产生如下的用户信息:
name: fido
groups:
- dogs
- dachshunds
extra:
scopes:
- openid
- profile
为了防止
--requestheader-client-ca-file
必需。PEM 编码的证书包。在检查用户名的请求header 之前,必须针对指定文件中的证书颁发机构提交并验证有效的客户端证书。--requestheader-allowed-names
可选。Common Name (cn)列表。如果设置了,则在检查用户名的请求header 之前, 必须提供指定列表中Common Name (cn)的有效客户端证书。如果为空,则允许使用任何Common Name 。
Keystone 密码
通过在启动过程中将 --experimental-keystone-url=<AuthURL>
选项传递给plugin/pkg/auth/authenticator/password/keystone/keystone.go
中实现,目前使用基本身份验证通过用户名和密码验证用户。
如果您为--experimental-keystone-ca-file=SOMEFILE
选项。如果您设置了该选项,experimental-keystone-ca-file
中的某个权威机构验证。否则,证书由主机的根证书颁发机构验证。
有关如何使用
匿名请求
启用时,未被其他已配置身份验证方法拒绝的请求将被视为匿名请求,并给予 system:anonymous
的用户名和 system:unuthenticated
的组名。
例如,在配置了令牌认证和启用了匿名访问的服务器上,提供无效的401 Unauthorized
错误。提供
在--anonymous-auth=false
选项给
在AlwaysAllow
以外的授权模式,则默认启用匿名访问,并且可以通过将 --anonymous-auth=false
选项传递给system:annoymous
或 system:unauthenticated
组,因此授予对 *
用户或 *
组访问权的传统策略规则不包括匿名用户。
用户模拟
用户可以通过模拟
模拟请求首先认证为请求用户,然后切换到模拟的用户信息。
- 用户使用他们的凭证和模拟
header 进行API 调用。 API server 认证用户API server 确保经过身份验证的用户具有模拟权限。- 请求用户的信息被替换为模拟值
- 请求被评估,授权作用于模拟的用户信息。
以下
Impersonate-User
:充当的用户名Impersonate-Group
:作为组名。可以多次使用来设置多个组。可选的,需要 “Impersonate-User”Impersonate-Extra-( extra name )
:用于将额外字段与用户关联的动态header 。可选。需要 “Impersonate-User”
一组示例
Impersonate-User: jane.doe@example.com
Impersonate-Group: developers
Impersonate-Group: admins
Impersonate-Extra-dn: cn=jane,ou=engineers,dc=example,dc=com
Impersonate-Extra-scopes: view
Impersonate-Extra-scopes: development
当使用 kubectl
的 --as
标志来配置Impersonate-User
--as-group
标志来配置Impersonate-Group
$ kubectl drain mynode
Error from server (Forbidden): User "clark" cannot get nodes at the cluster scope. (get nodes mynode)
$ kubectl drain mynode --as=superman --as-group=system:masters
node "mynode" cordoned
node "mynode" draine
为模仿用户、组或设置额外字段,模拟用户必须能够对正在模拟的属性的种类(“用户”
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: impersonator
rules:
- apiGroups: [""]
resources: ["users", "groups", "serviceaccounts"]
verbs: ["impersonate"]
额外的字段被评估为资源 “userextras” 的子资源。为了允许用户使用额外字段 “scope” 的模拟
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: scopes-impersonator
# Can set "Impersonate-Extra-scopes" header.
- apiGroups: ["authentication.k8s.io"]
resources: ["userextras/scopes"]
verbs: ["impersonate"]
模拟resourceNames
可以使用的资源来限制。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: limited-impersonator
rules:
# Can impersonate the user "jane.doe@example.com"
- apiGroups: [""]
resources: ["users"]
verbs: ["impersonate"]
resourceNames: ["jane.doe@example.com"]
# Can impersonate the groups "developers" and "admins"
- apiGroups: [""]
resources: ["groups"]
- verbs: ["impersonate"]
resourceNames: ["developers", "admins"]
# Can impersonate the extras field "scopes" with the values "view" and "development"
- apiGroups: ["authentication.k8s.io"]
resources: ["userextras/scopes"]
verbs: ["impersonate"]
resourceNames: ["view", "development"]
附录
创建证书
使用客户端证书进行身份验证时,可以使用现有的部署脚本或通过 easyrsa
或 openssl
手动生成证书。
使用已有的部署脚本
已有的部署脚本 在 cluster/saltbase/salt/generate-cert/make-ca-cert.sh
。
执行该脚本时需要传递两个参数。第一个参数是IP:<ip-address>
或 DNS:<dns-name>
。
该脚本将生成三个文件: ca.crt
、server.crt
和 server.key
。
最后,将一下参数添加到
--client-ca-file=/srv/kubernetes/ca.crt
--tls-cert-file=/srv/kubernetes/server.crt
--tls-private-key-file=/srv/kubernetes/server.key
easyrsa
-
下载,解压,并初始化修补版本的
easyrsa3 。curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz tar xzf easy-rsa.tar.gz cd easy-rsa-master/easyrsa3 ./easyrsa init-pki
-
生成
CA (使用--batch
设置为自动模式。使用--req-cn
设置默认的CN )./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass
-
生成服务器证书和密钥
。 (build-server-full [ 文件名] :生成一个键值对,在本地为客户端和服务器签名。 )./easyrsa --subject-alt-name="IP:${MASTER_IP}" build-server-full server nopass
-
复制
pki/ca.crt
, pki/issued/server.crt
和 pki/private/server.key
到您的目录下。 -
将以下参数添加到
API server 的启动参数中:--client-ca-file=/yourdirectory/ca.crt --tls-cert-file=/yourdirectory/server.crt --tls-private-key-file=/yourdirectory/server.key
openssl
-
生成一个
2048 bit 的ca.key :openssl genrsa -out ca.key 2048
-
根据
ca.key 生成一个ca.crt (使用-days 设置证书的有效时间) :openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt
-
生成一个
2048 bit 的server.key :openssl genrsa -out server.key 2048
-
根据
server.key 生成一个server.csr :openssl req -new -key server.key -subj "/CN=${MASTER_IP}" -out server.csr
-
根据
ca.key 、ca.crt 和server.csr 生成server.crt :openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000
-
查看证书:
openssl x509 -noout -text -in ./server.crt
最后,不要忘了向
认证API
您可以使用certificates.k8s.io