I’m creating a Kubernetes Secret with Pulumi, and ...
# kubernetes
l
I’m creating a Kubernetes Secret with Pulumi, and the secret information is added to the Secret in clear text as an annotation. Is this Pulumi who does this??? Code:
Copy code
const privatePullCredentials = new kubernetes.core.v1.Secret('dockerprivatepull', {
    type: "<http://kubernetes.io/dockerconfigjson|kubernetes.io/dockerconfigjson>",
    metadata: {
        namespace: namespace.metadata.name
    },
    stringData: {
        ".dockerconfigjson": config
            .requireSecret("docker-hub-token")
            .apply(value => {
                return JSON.stringify({
                    auths: {
                        "<https://index.docker.io/v1/>": {
                            auth: value
                        }
                    }
                })
            })
    }
});
Output:
Copy code
kubectl get secret dockerprivatepull-s2nimzmf --namespace=apps --output=yaml                                             master ● ↓2  10:43:53
apiVersion: v1
data:
  .dockerconfigjson: eyJhdXRocyI6eyJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOnsiYXV0aCI6ImRlOWM1NTgyLTM4ZTMtNGY1Mi04ZTFhLTk0NzgzNWQ2ZTc5YyJ9fX0=
kind: Secret
metadata:
  annotations:
    <http://kubectl.kubernetes.io/last-applied-configuration|kubectl.kubernetes.io/last-applied-configuration>: |
      {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{"<http://pulumi.com/autonamed|pulumi.com/autonamed>":"true"},"labels":{"<http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>":"pulumi"},"name":"dockerprivatepull-s2nimzmf","namespace":"apps"},"stringData":{".dockerconfigjson":"{\"auths\":{\"<https://index.docker.io/v1/>\":{\"auth\":\"<clear text secret here!!!>"}}}"},"type":"<http://kubernetes.io/dockerconfigjson|kubernetes.io/dockerconfigjson>"}
    <http://pulumi.com/autonamed|pulumi.com/autonamed>: "true"
  creationTimestamp: "2020-01-28T09:43:00Z"
  labels:
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: pulumi
  name: dockerprivatepull-s2nimzmf
  namespace: osimis
  resourceVersion: "935549"
  selfLink: /api/v1/namespaces/osimis/secrets/dockerprivatepull-s2nimzmf
  uid: c19731a4-45e9-414a-8a04-fb92ce5f05bd
type: <http://kubernetes.io/dockerconfigjson|kubernetes.io/dockerconfigjson>
b
wow, you’re right. it happens here too. looks like Pulumi uses
kubectl apply
to apply the secret, which makes . The “correct” way to do it seems like it would be to use
kubectl create
the first time, and then
kubectl replace
on subsequent updates, which does not retain a
last-applied-configuration
annotation (ref https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/) would you like to make a github issue? 😄
l
b
awesome work 👍
l
I added the pulumi & k8s provider versions to the ticket.
👍 1
b
hopefully someone who knows how this works will pick up on it soon. I have a feeling it’s going to have to be fixed in the terraform provider though…
l
@broad-helmet-79436 don’t think so as the Pulumi k8s provider is one that doesn’t depend on the TF provider. 😉
b
oh, you’re right!
fingers crossed this can be resolved quickly then. good catch 🙂
@gorgeous-egg-16927 if you have a minute, I would like to discuss a bit regarding the issue I filed on GH. For me, the issue is the annotation which is added, I guess by Pulumi.
g
Sure, interested to hear more
l
I would like to find out about the difference in the two scenarios: 1. I create a secret via CLI:
kubectl create secret …
and with
kubectl get secret ...
I get a secret without annotation. 2. I create a secret via Pulumi. With
kubectl get secret
I get a secret with the annotation. So is Pulumi doing something different from the CLI?
g
Generally
kubectl
adds the same annotation, but it might not for Secrets; I’d have to check. Pulumi’s k8s provider adds that annotation to help with client-side diffing.
It should be compatible with `kubectl`’s usage
Huh, just confirmed that
kubectl
doesn’t add that annotation. Wasn’t aware of that before.
l
@gorgeous-egg-16927 so is the GH issue I filed a bug then which will be fixed? It’s a small thing in the end, given that the secret data is only base64 encoded.
g
I’m chatting with my colleague about it now. It might make more sense for us to always replace Secret resources on update, and get rid of the annotation.
Let’s keep the issue open for now, and I’ll update with any new info
👍🏼 1