4、K8S 证书说明
1、K8S 证书列表说明 https://www.jianshu.com/p/549ab7a059b0
1.1、How certificates are used by your clusterKubernetes requires PKI for the following operations:
etcd also implements mutual TLS to authenticate clients and peers. etcd还实现了双向TLS来对客户端和对等方进行身份验证。 1.2、Where certificates are stored存储证书的位置If you install Kubernetes with kubeadm, certificates are stored in 1.3、Configure certificates manually手动配置证书If you don't want kubeadm to generate the required certificates, you can create them in either of the following ways. Single root CAYou can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself. 您可以创建由管理员控制的单个根CA。然后，该根CA可以创建多个中间CA，并将所有进一步的创建委托给Kubernetes本身。 Required CAs:
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, 除了上述CA之外，还必须获得用于service account管理的公共/私有密钥对sa.key和sa.pub。 All certificatesIf you don't wish to copy the CA private keys to your cluster, you can generate all certificates yourself. Required certificates:
[1]: any other IP or DNS name you contact your cluster on (as used by kubeadm the load balancer stable IP and/or DNS name, where
Certificate pathsCertificates should be placed in a recommended path (as used by kubeadm). Paths should be specified using the given argument regardless of location.
Same considerations apply for the service account key pair:
1.4、Configure certificates for user accounts配置用户帐户的证书You must manually configure these administrator account and service accounts:
These files are used as follows:
|
2、配置聚合层允许kubernetes apiserver使用其他api进行扩展，这些api不是核心kubernetesapi的一部分。
要使聚合层在您的环境中正常运行以支持代理服务器和扩展apiserver之间的相互TLS身份验证，需要满足一些设置要求
Kubernetes和kube-apiserver具有多个CA，因此请确保代理是由聚合层CA签名的，而不是由主CA签名的。
认证流程：
与自定义资源定义（CRD）不同，聚合API除了标准的Kubernetes apiserver之外，还涉及另一台服务器-您的扩展apiserver，Kubernetes apiserver将需要与您的扩展apiserver通信，并且您的扩展apiserver将需要与Kubernetes apiserver通信，为了确保此通信的安全，Kubernetes apiserver使用x509证书向扩展apiserver进行身份验证。
本节介绍身份验证和授权流的工作方式以及如何配置它们。
Kubernetes apiserver：对发出请求的用户进行身份验证，并授权其对请求的API路径的权限。
Kubernetes apiserver：将请求代理到扩展apiserver
扩展apiserver：验证来自Kubernetes apiserver的请求
扩展apiserver：授权来自原始用户的请求
扩展apiserver：执行
2.1、本节的其余部分详细描述了这些步骤。该流程可以在下图中看到。
1、Kubernetes Apiserver Authentication and Authorization
对扩展apiserver提供的API路径的请求与所有API请求的开始方式相同：与Kubernetes apiserver通信。此路径已由扩展apiserver向Kubernetes apiserver注册。
用户与Kubernetes apiserver通信，请求访问路径。 Kubernetes apiserver使用通过Kubernetes apiserver配置的标准身份验证和授权来验证用户并授权对特定路径的访问。
For an overview of authenticating to a Kubernetes cluster, see "Authenticating to a Cluster"认证. For an overview of authorization of access to Kubernetes cluster resources, see "Authorization Overview"授权.
到目前为止，所有内容都是标准的Kubernetes API请求，身份验证和授权。
Kubernetes apiserver现在准备将请求发送到扩展apiserver
2、Kubernetes Apiserver Proxies the Request
Kubernetes apiserver现在将向注册处理此请求的扩展apiserver发送或代理请求。为此，它需要知道以下几点：
2.1、Kubernetes apiserver应该如何向扩展apiserver进行身份验证，以通知扩展apiserver通过网络发出的请求来自有效的Kubernetes apiserver？
2.2、Kubernetes apiserver应该如何向扩展apiserver通知对其原始请求进行身份验证的用户名和组？
为了提供这两个，您必须使用多个标志配置Kubernetes apiserver
3、Kubernetes Apiserver Client Authentication
Kubernetes apiserver通过TLS连接到扩展apiserver，并使用客户端证书进行身份验证。您必须在启动时使用提供的标志向Kubernetes apiserver提供以下内容：
- private key file via
--proxy-client-key-file - signed client certificate file via
--proxy-client-cert-file - certificate of the CA that signed the client certificate file via
--requestheader-client-ca-file - valid Common Name values (CNs) in the signed client certificate via
--requestheader-allowed-names
Kubernetes apiserver将使用--proxy-client-*-file指示的文件对扩展apiserver进行身份验证。为了使兼容扩展apiserver将该请求视为有效，必须满足以下条件：
- 必须使用由CA签名的客户端证书建立连接，该ca的证书位于--requestheader-client-ca-file中
- 必须使用其CN是--requestheader allowed names中列出的内容之一的客户端证书建立连接
注意：您可以将此选项设置为空白，即--requestheader-allowed-names =“”。这将向扩展apiserver指示任何CN都是可接受的。
使用这些选项启动时，Kubernetes apiserver将：
- 使用它们对扩展服务器进行身份验证。
- 在kube-system命名空间中创建一个名为extension apiserver authentication的configmap，它将在其中放置CA证书和允许的CNs。反过来，扩展服务器可以检索这些信息来验证请求。
请注意，Kubernetes apiserver使用相同的客户端证书对所有扩展apiserver进行身份验证。它不会为每个扩展apiserver创建一个客户机证书，而是创建一个作为Kubernetes apiserver进行身份验证的证书。对于所有扩展apiserver请求，都会重用同一个。
4、Original Request Username and Group
当Kubernetes apiserver将请求代理到扩展apiserver时，它将通知扩展apiserver用户名和组，原始请求已成功通过该用户名和组进行了身份验证
它在其代理请求的http标头中提供了这些信息。您必须将要使用的标头名称告知Kubernetes apiserver。
- the header in which to store the username via
--requestheader-username-headers - the header in which to store the group via
--requestheader-group-headers - the prefix to append to all extra headers via
--requestheader-extra-headers-prefix
这些标头名称也放置在extension-apiserver-authentication configmap中，因此扩展apiserver可以检索和使用它们
5、Extension Apiserver Authenticates the Request
扩展apiserver在收到来自Kubernetes apiserver的代理请求后，必须验证该请求确实确实来自有效的身份验证代理，该身份验证代理由Kubernetes apiserver履行。扩展apiserver通过以下方式对其进行验证：
如上所述，从kube-system的configmap中检索以下内容：
- 客户端CA证书
- 允许的名称（CN）列表
- 用户名，组和其他信息的标头名称
使用以下客户端证书检查TLS连接是否已通过身份验证：
- 由其证书与检索到的CA证书匹配的CA签名。
- 在允许的CN列表中有一个CN，除非列表为空（在这种情况下，所有CN都被允许）。
- 从相应的标头中提取用户名和组
Was signed by the CA whose certificate matches the retrieved CA certificate.
如果上述过程通过，则该请求是来自合法身份验证代理（在本例中是Kubernetes apiserver）的有效代理请求。
请注意，扩展apiserver实现负责提供上述功能。许多默认情况下是这样做的，利用k8s.io/apiserver/包。其他人可以使用命令行选项提供覆盖它的选项。
为了获得检索configmap的权限，扩展服务器需要相应的角色。kube-system命名空间中有一个名为extension apiserver authentication reader的默认角色，可以分配该角色
--requestheader-allowed-names=front-proxy-client对应cm如下
kubectl get cm extension-apiserver-authentication -n kube-system -oyaml
apiVersion: v1
data:
client-ca-file: |
-----BEGIN CERTIFICATE-----
MIIDejCCAmKgAwIBAgIUbqgbnLVub4spN2jKLNcn9wT+VXQwDQYJKoZIhvcNAQEL
BQAwQzELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaWppbmcxEDAOBgNVBAcTB0Jl
aWppbmcxEDAOBgNVBAMTB2V0Y2QgQ0EwHhcNMjAxMjMwMDc0OTAwWhcNMjUxMjI5
MDc0OTAwWjBDMQswCQYDVQQGEwJDTjEQMA4GA1UECBMHQmVpamluZzEQMA4GA1UE
BxMHQmVpamluZzEQMA4GA1UEAxMHZXRjZCBDQTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJ5c6J1jLowz/Q8gel4jut6vO4s8MAnvgViIlNXAyGoRo7R/
n8sxaYN/ts5yHX7CU49ZhUOxd41MAuBfuUFd+kUR8kJ5otRpAe7QSQqJ4Kx2vjcG
uqtFWFLc2Q1PR3751cAPjbeFwX0m1q8XXPwjig3UeQi1av37VeNW8iKqs9ZAQ8mW
VQ42ceEwK8O6RzqH6YMFR6BEeE/22zlhMNrdlsQ9B7PBGs3jWlHljZ0LyryMMA9y
Wi0RBzXhYXLp72VKliNKK2KuaUgQOuZGPF7aEIbdyo0ectX1J6c0UgZqIYS2HsEH
I00xvUE/eTxluy8w/HOulsMJqPl5SWYxOwyE3Y0CAwEAAaNmMGQwDgYDVR0PAQH/
BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQIwHQYDVR0OBBYEFMmFz/coesIglm6G
GvIGoz0gSCOQMB8GA1UdIwQYMBaAFMmFz/coesIglm6GGvIGoz0gSCOQMA0GCSqG
SIb3DQEBCwUAA4IBAQAYA0Hu+C2EcuYqqp7Pdkv0w8JIF14SAbUUQUpqmeXnRfHV
N9Va3zT1A2jQ5rSZupBL33S6SU+ayOpvLM+2334wJGE5tZTOYga79vyGuh/W1q1l
K/RHFB/RfYKR+NOjFDi8o7GwtkO1jeegfrqXAW77aEP1Ndl6PUm95a+PsUUTgsit
7fMn0OFgWCOq6DGucP3THalz7tFW+OR5cZZ1XLjkRVDSEGFRVrSWS+g5chmfkuzo
4GJC4+bxdgjznAiavUlBCgIc0SjZmQTxqFqHdmZkmRcVD0zBiVQfwFzM+7EFrqBu
2b9UqvBPfI8q04cqSbhxzQjq15OYNvII03g1YzFa
-----END CERTIFICATE-----
requestheader-allowed-names: '["aggregator","front-proxy-client"]'
requestheader-client-ca-file: |
-----BEGIN CERTIFICATE-----
MIIDejCCAmKgAwIBAgIUbqgbnLVub4spN2jKLNcn9wT+VXQwDQYJKoZIhvcNAQEL
BQAwQzELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaWppbmcxEDAOBgNVBAcTB0Jl
aWppbmcxEDAOBgNVBAMTB2V0Y2QgQ0EwHhcNMjAxMjMwMDc0OTAwWhcNMjUxMjI5
MDc0OTAwWjBDMQswCQYDVQQGEwJDTjEQMA4GA1UECBMHQmVpamluZzEQMA4GA1UE
BxMHQmVpamluZzEQMA4GA1UEAxMHZXRjZCBDQTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAJ5c6J1jLowz/Q8gel4jut6vO4s8MAnvgViIlNXAyGoRo7R/
n8sxaYN/ts5yHX7CU49ZhUOxd41MAuBfuUFd+kUR8kJ5otRpAe7QSQqJ4Kx2vjcG
uqtFWFLc2Q1PR3751cAPjbeFwX0m1q8XXPwjig3UeQi1av37VeNW8iKqs9ZAQ8mW
VQ42ceEwK8O6RzqH6YMFR6BEeE/22zlhMNrdlsQ9B7PBGs3jWlHljZ0LyryMMA9y
Wi0RBzXhYXLp72VKliNKK2KuaUgQOuZGPF7aEIbdyo0ectX1J6c0UgZqIYS2HsEH
I00xvUE/eTxluy8w/HOulsMJqPl5SWYxOwyE3Y0CAwEAAaNmMGQwDgYDVR0PAQH/
BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQIwHQYDVR0OBBYEFMmFz/coesIglm6G
GvIGoz0gSCOQMB8GA1UdIwQYMBaAFMmFz/coesIglm6GGvIGoz0gSCOQMA0GCSqG
SIb3DQEBCwUAA4IBAQAYA0Hu+C2EcuYqqp7Pdkv0w8JIF14SAbUUQUpqmeXnRfHV
N9Va3zT1A2jQ5rSZupBL33S6SU+ayOpvLM+2334wJGE5tZTOYga79vyGuh/W1q1l
K/RHFB/RfYKR+NOjFDi8o7GwtkO1jeegfrqXAW77aEP1Ndl6PUm95a+PsUUTgsit
7fMn0OFgWCOq6DGucP3THalz7tFW+OR5cZZ1XLjkRVDSEGFRVrSWS+g5chmfkuzo
4GJC4+bxdgjznAiavUlBCgIc0SjZmQTxqFqHdmZkmRcVD0zBiVQfwFzM+7EFrqBu
2b9UqvBPfI8q04cqSbhxzQjq15OYNvII03g1YzFa
-----END CERTIFICATE-----
requestheader-extra-headers-prefix: '["X-Remote-Extra-"]'
requestheader-group-headers: '["X-Remote-Group"]'
requestheader-username-headers: '["X-Remote-User"]'
kind: ConfigMap
metadata:
creationTimestamp: "2020-12-30T14:43:46Z"
name: extension-apiserver-authentication
namespace: kube-system
resourceVersion: "5063327"
selfLink: /api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication
uid: 49c22e94-880e-456a-b3df-c3c4c3e04e4d
# kubectl get role extension-apiserver-authentication-reader -n kube-system -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: "2020-12-30T14:43:56Z"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: extension-apiserver-authentication-reader
namespace: kube-system
resourceVersion: "136"
selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/kube-system/roles/extension-apiserver-authentication-reader
uid: fd2bf774-3f0b-40b9-9108-24b9beeda0ac
rules:
- apiGroups:
- ""
resourceNames:
- extension-apiserver-authentication
resources:
- configmaps
verbs:
- get
- list
- watch
6、Extension Apiserver Authorizes the Request
扩展apiserver现在可以验证从头部检索到的用户/组是否有权执行给定的请求。它通过向Kubernetes apis服务器发送一个标准SubjectAccessReview请求来实现。
为了使扩展apiserver本身被授权可以将SubjectAccessReview请求提交给Kubernetes apiserver，它需要正确的权限。 Kubernetes包含一个默认的ClusterRole，名为system：auth-delegator，具有适当的权限。可以将其授予扩展apiserver的服务帐户。
kubectl get clusterrole system:auth-delegator -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: "2020-12-30T14:43:56Z"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: system:auth-delegator
resourceVersion: "64"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Aauth-delegator
uid: 9dd97ade-aa90-4080-b5ea-298c45a33bdc
rules:
- apiGroups:
- authentication.k8s.io
resources:
- tokenreviews
verbs:
- create
- apiGroups:
- authorization.k8s.io
resources:
- subjectaccessreviews
verbs:
- create
7、Extension Apiserver Executes
如果SubjectAccessReview通过，则扩展apiserver将执行请求。
启用Kubernetes Apiserver标志
通过以下kube-apiserver标志启用聚合层。
-requestheader-client-ca-file=<path to aggregator CA cert>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to aggregator proxy cert>
--proxy-client-key-file=<path to aggregator proxy key>2.2、 CA Reusage and Conflicts
Kubernetes apiserver有两个客户端CA选项：
--client-ca-file--requestheader-client-ca-file
这些功能中的每一个都是独立的，如果使用不当，它们之间可能会发生冲突。
--client-ca-file: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file referenced by--client-ca-file, then the request is treated as a legitimate request, and the user is the value of the common nameCN=, while the group is the organizationO=. See the documentation on TLS authentication.当请求到达Kubernetes apiserver时，如果启用此选项，Kubernetes apiserver将检查请求的证书。如果它是由--client CA file引用的文件中的某个CA证书签名的，则该请求将被视为合法请求，并且用户是公共名称CN=的值，而组是组织O=。请参阅有关TLS身份验证的文档。- 根据用户名具有的权限进行授权？？？？？？？？
- 根据用户名具有的权限进行授权？？？？？？？？
--requestheader-client-ca-file: When a request arrives to the Kubernetes apiserver, if this option is enabled, the Kubernetes apiserver checks the certificate of the request. If it is signed by one of the CA certificates in the file reference by--requestheader-client-ca-file, then the request is treated as a potentially legitimate request. The Kubernetes apiserver then checks if the common nameCN=is one of the names in the list provided by--requestheader-allowed-names. If the name is allowed, the request is approved; if it is not, the request is not.
当请求到达Kubernetes apiserver时，如果启用此选项，Kubernetes apiserver将检查请求的证书。如果它是由--requestheader-client-ca-file文件引用中的一个CA证书签名的，那么该请求将被视为一个潜在的合法请求。然后Kubernetes apiserver检查公共名CN=是否是--requestheader allowed names提供的列表中的一个名称。如果名称允许，则请求被批准；如果不允许，则请求不被批准。
如果同时提供了--client-ca-file和--requestheader-client-ca-file，则请求首先检查--requestheader-client-ca-file CA，然后再检查--client-ca-file。通常，对于这些选项中的每一个，都使用不同的CA，即根CA或中间CA。常规客户端请求与--client-ca-file匹配，而聚合请求与--requestheader-client-ca-file匹配。但是，如果两个都使用相同的CA，则通常会通过--client-ca-file传递的客户端请求将失败，因为CA将匹配--requestheader-client-ca-file中的CA，但公共名称CN=将不匹配--requestheader-allowed-names允许名称中可接受的公共名称之一。这可能会导致kubelets和其他控制平面组件以及终端用户无法通过Kubernetes apis服务器的身份验证。
或出于这个原因，请使用不同的证书授权。--client-ca-file选项-授权控制平面组件和终端用 --requestheader-client-ca-file选项授权聚合apiserver请求。
警告：除非您了解保护CA使用的风险和机制，否则不要重用在不同上下文中使用的CA。
如果您没有在运行API服务器的主机上运行kube代理，则必须确保系统已启用以下kube apiserver标志：
--enable-aggregator-routing=true2.3、Register APIService objects
您可以动态配置将哪些客户端请求代理到扩展apiserver。以下是注册示例：
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
name: <name of the registration object>
spec:
group: <API group name this extension apiserver hosts>
version: <API version this extension apiserver hosts>
groupPriorityMinimum: <priority this APIService for this group, see API documentation>
versionPriority: <prioritizes ordering of this version within a group, see API documentation>
service:
namespace: <namespace of the extension apiserver service>
name: <name of the extension apiserver service>
caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
2.4、Contacting the extension apiserver
一旦Kubernetes apiserver确定应将请求发送到扩展apiserver，它就需要知道如何联系它。
service字段是对扩展apiserver的服务的引用。服务命名空间和名称是必需的。端口是可选的，默认为443。
下面是一个扩展apiserver的示例，它被配置为在端口“1234”上调用，并根据ServerName my-service-name.my-service-namespace.svc验证TLS连接。
apiVersion: apiregistration.k8s.io/v1
kind: APIService
...
spec:
...
service:
namespace: my-service-namespace
name: my-service-name
port: 1234
caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
...
2.5、What's next
- Setup an extension api-server to work with the aggregation layer.
- For a high level overview, see Extending the Kubernetes API with the aggregation layer.
- Learn how to Extend the Kubernetes API Using Custom Resource Definitions.
3、Setup an extension api-server
设置扩展API服务器以与聚合层一起使用，可以使用其他API扩展Kubernetes apiserver，而这些API并不是核心Kubernetes API的一部分
下面的步骤描述如何在高层设置扩展服务器。无论您使用的是YAML配置还是api，这些步骤都适用。试图明确指出两者之间的任何差异。有关如何使用YAML配置实现它们的具体示例，可以查看Kubernetes repo中的示例apiserver。sample-apiserver或者，您可以使用现有的第三方解决方案，例如apiserver-builder,，它应该为您生成一个框架并自动执行以下所有步骤。
|
1、确保启用了apiservice api（检查--runtime config）。默认情况下，它应该是打开的，除非在集群中故意关闭它。 |
4、Extending the Kubernetes API with the aggregation layer
Aggregation layer
聚合层与kube apiserver一起运行。在注册扩展资源之前，聚合层将什么也不做。要注册一个API，需要添加一个APIService对象，该对象“声明”kubernetes api中的URL路径。此时，聚合层将代理发送该API路径的任何内容（例如/apis/myextension.mycompany.io/v1/…）到注册的APIService。
实施APIService的最常见方法是在集群中运行的Pod中运行扩展API服务器。如果您使用扩展API服务器来管理集群中的资源，则扩展API服务器（也称为“扩展-api服务器”）通常与一个或多个控制器配对。 apiserver-builder库为扩展API服务器和关联的控制器提供了框架。
Response latency
扩展API服务器应该与kube apis服务器之间具有低延迟的网络连接。发现请求需要在5秒或更短的时间内从kube apis服务器往返。
如果您的扩展API服务器无法达到延迟要求，请考虑进行更改以满足该要求。您还可以在kube apiserver上设置enableagggregateddiscoverytimeout=false功能门来禁用超时限制。此不推荐使用的功能门将在将来的版本中删除。
What's next
- To get the aggregator working in your environment, configure the aggregation layer.
- Then, setup an extension api-server to work with the aggregation layer.
- Also, learn how to extend the Kubernetes API using Custom Resource Definitions.
- Read the specification for APIService
5、Extend the Kubernetes API with CustomResourceDefinitions
今天让我们聊聊 Kubernetes 的公私钥和证书认证。
本文内容会提及如何根据需要对 CA、公私钥进行组织并对集群进行设置。
Kubernetes 的组件中有很多不同的地方可以放置证书之类的东西。在进行集群安装的时候，我感觉有一百多亿个不同的命令参数是用来设置证书、密钥的，真不明白是怎么弄到一起工作的。
当然了，没有一百亿那么多的参数，不过的确很多的。比如 API Server 的参数吧，有大概 16 个参数是跟这些东西有关的（下面是节选）：
--cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes")
--client-ca-file string If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
--etcd-certfile string SSL certification file used to secure etcd communication.
--etcd-keyfile string SSL key file used to secure etcd communication.
--kubelet-certificate-authority string Path to a cert file for the certificate authority.
--kubelet-client-certificate string Path to a client cert file for TLS.
--kubelet-client-key string Path to a client key file for TLS.
--proxy-client-cert-file string Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components recieving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification.
--proxy-client-key-file string Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins.
--requestheader