0

I have ran the following bash script to create secret for a service account

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: cicd-secret
  annotations:
    kubernetes.io/service-account.name: cicd
type: kubernetes.io/service-account-token
EOF

secret/cicd-secret created

After successfull creation when i am running Kubectl command then it is not listing. Out put of the commnds are:

$ kubectl get secrets
No resources found in default namespace.

kishan.kumar@kkumar-xps15 MINGW64 ~
$ kubectl get secrets -n weatherdispatch
No resources found in weatherdispatch namespace.

When i have listed service account then there also it is not showing secrets for my service account 'cicd':

$ kubectl get sa -n weatherdispatch
NAME              SECRETS   AGE
azdev-sa-d44a1a   0         41h
azdev-sa-f4a5ae   0         22h
cicd              0         16h
default           0         41h

Can someone please help me on this :) Thanks in advance.

I am creating secrets manually because Kubernetes 1.24+ does not create secrets automatically.

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Kishan Kumar
  • 23
  • 1
  • 5

1 Answers1

0

Unless your context is set to use the weatherdispatch namespace, you are attempting to create the secret in the default namespace, which doesn't have a cicd serviceaccount, so it doesn't create one even though it says it does.

Remember to specify your namespace on any action where it's relevant.

kubectl -n weatherdispatch apply -f - <<< "---
apiVersion: v1
kind: Secret
metadata:
  name: cicd-secret
  annotations:
    kubernetes.io/service-account.name: cicd
type: kubernetes.io/service-account-token"

Also, there's no data.

With no data: section or equivalent, you're going to have to add it later anyway. I understand you might have redacted it.

A here-doc will work here, but seems like a lot of work to avoid a little work. If you were just making your example concise, better to show what you're actually doing than risk introducing other issues. I used a here-string - personal preference, not better.

Paul Hodges
  • 13,382
  • 1
  • 17
  • 36