<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.): No</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): PKI</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one):<br>
FEATURE REQUEST</p>

<p dir="auto">The kubernetes API server can now act as a PKI to service Certificate Signing Requests for kubelets and set up secured and authenticated TLS communications between the API server and kubelets. kubeadm makes use of this API endpoint. In order to provide this endpoint, the CA key must be present on the master (or API server) to be able to sign certificates.</p>
<p dir="auto">It should be clear that having a CA key, or more clearly the ability to sign new certificates, as a permanent part of the cluster could be considered weaker security than not. If the cluster gets hacked, one admittedly already has problems, but in terms of security it is common to think in terms of having layers of security so that if one barrier gets broken, there are still more to overcome.</p>
<p dir="auto">It could make sense then to support somehow provisioning certificates in a way that the cluster does not retain the capability to provision new certificates while a cluster operator/administrator is not actively managing the cluster, so to speak. This could be in the form of kubeadm using a temporary token to interact with an external PKI such that when the kubeadm provisioning session is completed, no further certificates can be provisioned from the PKI with that token. Something along those lines.</p>
<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>):</p>
<p dir="auto">1.4.3</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: N/A</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): N/A</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): N/A</li>
<li><strong>Install tools</strong>: kubeadm</li>
<li><strong>Others</strong>: N/A</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
kubeadm generated a CA key on the master and retained it. kubelets sent their CSRs to the master API server in order to provision certificates.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
I expected the above to happen, but the proposal is that if security is particularly important, the CA key and ability to provision new TLS certificates does not remain part of the cluster but is a separate concern that is separately managed.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
Use kubeadm to deploy a cluster.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">This is a proposal to implement caching selector result. <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="58944257" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/4817" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/4817/hovercard?comment_id=76495394&amp;comment_type=issue_comment" href="https://github.com/kubernetes/kubernetes/issues/4817#issuecomment-76495394">#4817 (comment)</a></p>
<p dir="auto">AFAIK, currently only <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md#api">two components</a> use selector to group their members: <code class="notranslate">service</code> and <code class="notranslate">replicationController</code>, and they get list of their members by matching seletor against all pods' label every time.</p>
<p dir="auto">Here I propose a way to cache seletor result in etcd.</p>
<p dir="auto">Define a new registry in etcd: selector.</p>
<p dir="auto">Whenever a <code class="notranslate">service</code> or <code class="notranslate">replicationController</code> is created, generate <a href="https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/identifiers.md#uids">uid</a> for its selector, and register selector with that uid in etcd. While creating <code class="notranslate">service</code> or <code class="notranslate">replicationController</code>, it watches that selector in etcd to wait updates on result of selector. We should add pre-existed matched pods to its result of course.</p>
<p dir="auto">And whenever a <code class="notranslate">pod</code> is created, matches its label with all selector under its namespace (assuming we forbidden selector select object in another ns, which I not quite sure), and add that pod to selector result if match. Update or delete a <code class="notranslate">pod</code> should also update all selectors' result under its ns.</p>
<p dir="auto">When a <code class="notranslate">selector</code> and <code class="notranslate">pod</code> is created at same time, we should use some kind of mutex to avoid race condition.</p>
<p dir="auto">Any comment?</p>