<p>Ref: <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers" rel="nofollow noreferrer">https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers</a></p>
<p>According to the docs</p>
<blockquote>
<p>Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.</p>
</blockquote>
<p><code>When set as the first provider, the resource will be decrypted as new values are written.</code> sounds confusing. If resources are written as is with no encryption into etcd, why does <code>decrypted as new values are written</code> mean ?</p>
<p>And following that</p>
<blockquote>
<p>By default, the identity provider is used to protect secrets in etcd, which provides no encryption.</p>
</blockquote>
<p>What kind of security does <code>identity</code> provider give if no encryption happens and if encryption happens, what kind of encryption is it?</p>

vadasambar
<p>As stated in <code>etcd</code> about <a href="https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/security.md#does-etcd-encrypt-data-stored-on-disk-drives" rel="nofollow noreferrer">security</a></p>
<blockquote>
<p>Does etcd encrypt data stored on disk drives?</p>
</blockquote>
<p>No. etcd doesn't encrypt key/value data stored on disk drives. If a user need to encrypt data stored on etcd, there are some options:</p>
<ul>
<li>Let client applications encrypt and decrypt the data</li>
<li>Use a feature of underlying storage systems for encrypting stored data like dm-crypt</li>
</ul>
<h2>First part of the question:</h2>
<blockquote>
<p>By default, the <code>identity provider</code> is used to protect secrets in etcd, which provides no encryption.
It means that by default k8s api is using <code>identity provider</code> while storing secrets in <code>etcd</code> and it <strong>doesn't provide any encryption.</strong></p>
</blockquote>
<p>Using <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/" rel="nofollow noreferrer">EncryptionConfiguration</a> with the only one provider: <code>identity</code> gives you the same result as not using <code>EncryptionConfiguration</code> at all (assuming you didn't have any encrypted secrets before at all).
All secret data will be stored in plain text in <code>etcd</code>.</p>
<p>Example:</p>
<pre><code>    providers:
    - identity: {}
</code></pre>
<h2>Second part of your question:</h2>
<blockquote>
<p>Resources written as-is without encryption.
This is described and explained in the first part of the question</p>
</blockquote>
<p>When set as the first provider, the resource will be decrypted as new values are written.</p>
<p>Take a look at this example:</p>
<pre><code>    providers:
    - aescbc:
        keys:
        - name: key1
          secret: &lt;BASE 64 ENCODED SECRET&gt;
    - identity: {}
</code></pre>
<p>What this configuration means for you:</p>
<ul>
<li>The new provider introduced into your <code>EncryptionConfiguration</code> does not affect existing data.</li>
<li>All existing <code>secrets</code> in <code>etcd</code> (before this configuration has been applied) are still in plain text.</li>
<li>Starting with this configuration all new <code>secrets</code> will be saved using <code>aescbc</code> encryption. All new <code>secrets</code> in <code>etcd</code> will have prefix <code>k8s:enc:aescbc:v1:key1</code>.</li>
<li>In this scenario you will have in <code>etcd</code> a mixture of encrypted and not encrypted data.</li>
</ul>
<p>So the question is why we are using those two providers?</p>
<ul>
<li>provider: <code>aescbc</code> is used to write new <code>secrets</code> as encrypted data during write operation and to decrypt existing <code>secrets</code> during read operation.</li>
<li>provider: <code>identity</code> is still necessary to read all not encrypted secrets.</li>
</ul>
<p>Now we are switching our providers in <code>EncryptionConfiguration</code>:</p>
<pre><code>    providers:
    - identity: {}
    - aescbc:
        keys:
        - name: key1
          secret: &lt;BASE 64 ENCODED SECRET&gt;
</code></pre>
<ul>
<li>In this scenario you will have in <code>etcd</code> a mixture of encrypted and not encrypted data.</li>
<li>Starting with this configuration all new <code>secrets</code> will be saved in plain text</li>
<li>For all existing secrets in etcd with prefix k8s:enc:aescbc:v1:key1 provider: aescbc configuration will be used to decrypt existing secrets stored in etcd.</li>
</ul>
<blockquote>
<p>When set as the first provider, the resource will be decrypted as new values are written</p>
</blockquote>
<p>In order to switch from <code>mixture of encrypted and not encrypted data</code> into scenario that we have only &quot;not encrypted&quot; data, you should perform read/write operation for all secrets:</p>
<p><code>$ kubectl get secrets --all-namespaces -o json | kubectl replace -f -</code></p>
<blockquote>
<p>why's it there if it offers no encryption but the docs seem to talk about decryption and how it protects.</p>
</blockquote>
<p>It's necessary to have the provider type of <code>identity</code> if you have a mixture of encrypted and not encrypted data
or if you want to decrypt all existing <code>secrets</code> (stored in etcd) encrypted by another provider.</p>
<p>The following command reads all secrets and then updates them to apply server side encryption. More details can be found in <a href="https://kubernetes.io/docs/tasks/administer-cluster/kms-provider/#ensuring-all-secrets-are-encrypted" rel="nofollow noreferrer">this paragraph</a></p>
<p><code>$ kubectl get secrets --all-namespaces -o json | kubectl replace -f -</code></p>
<p>Depending on your <code>EncryptionConfiguration</code>, all <code>secrets</code> will be saved as not encrypted -if the first provider is: <code>identity</code> or encrypted if the first provider is different type.</p>
<p><strong>In addtion</strong></p>
<p><code>EncryptionConfig</code> is disabled as default setting. To use it, you have to add <code>--encryption-provider-config</code> in your <code>kube-apiserver</code> configuration. <code>Identity</code> is not encrypting any data, as per <a href="https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers" rel="nofollow noreferrer">Encrypted Providers documentation</a> it has 3x <code>N/A</code>.</p>
