<p>So when creating secrets I often will use:</p>
<pre class="lang-sh prettyprint-override"><code>kubectl create secret generic super-secret --from-env-file=secrets
</code></pre>
<p>However, I wanted to move this to a dedicated secrets.yaml file, of kind &quot;Secret&quot; as per the documentation: <a href="https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-generic-em-" rel="nofollow noreferrer">https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-generic-em-</a></p>
<p>However, to do this, I need to base64 encode all of the secrets. Wha! This is bad imho. Why can't kubectl handle this for us? (Another debate for another day).</p>
<p>So, I am back to using the <code>kubectl create secret</code> command which works really well for ease of deployment - however, I am wondering what the process is to apply said creation of secret to a specific namespace? (Again, this probably would involve something tricky to get things to work - but why it's not a standard feature yet is a little worrying?)</p>

Micheal J. Roberts
<p>You can provide <code>stringData</code> section of a Secret instead of <code>data</code> section. That won't require base64 encoding. Here, is an example:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
  namespace: demo
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: t0p-Secret
</code></pre>
<p>Ref: <a href="https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret</a></p>
