I'd like to restore a kubernetes service account token from a backup (which is actually just an export of the corresponding secret):
apiVersion: v1
kind: Secret
metadata:
name: my-service-account-token-lqrvp
annotations:
kubernetes.io/service-account.name: my-service-account
type: kubernetes.io/service-account-token
data:
token: bXktc2ltcGxlLXRva2VuCg==
The secret has been applied successfully and was added to the service account:
# kubectl apply -f my-service-account.yaml
secret/my-service-account-token-lqrvp created
# kubectl describe sa my-service-account
Name: my-service-account
Namespace: my-namespace
Labels: <none>
Annotations: kubernetes.io/service-account.name: my-service-account
Image pull secrets: my-service-account-dockercfg-lv9hp
Mountable secrets: my-service-account-token-lv9hp
Tokens: my-service-account-token-lqrvp
Events: <none>
Unfortunately, everytime I try to access the api using the token, I always get the error "The token provided is invalid or expired":
# kubectl login https://api.my-k8s-cluster.mydomain.com:6443 --token=my-simple-token
error: The token provided is invalid or expired
I know that the token is usually automatically generated by the controller-manager, but is restoring a token supported by kubernetes?
Related
I realized ServiceAccount token secrets are no longer automatically generated in k8s 1.24. So I manually created a secret and attached it to the Service Account I created, but I found Mountable Secrets part is still empty, and I didn't find a way how to attach it to my Service Account.
apiVersion: v1
kind: ServiceAccount
metadata:
name: spinnaker-sa
namespace: spinnaker
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
name: sa-token
namespace: spinnaker
annotations:
kubernetes.io/service-account.name: "spinnaker-sa"
kubernetes.io/enforce-mountable-secrets: "true"
After I applied the above yaml file, I got the following result when I try kubectl describe serviceaccount
Name: spinnaker-sa
Namespace: spinnaker
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: <none>
Tokens: sa-token
Events: <none>
Pls advise what I should do to add Mountable secrets. Thanks!
I'm trying to run my kuberntes app using minikube on ubuntu20.04 and applied a secret to pull a private docker image from docker hub, but it doesn't seem to work correctly.
Failed to pull image "xxx/node-graphql:latest": rpc error: code
= Unknown desc = Error response from daemon: pull access denied for xxx/node-graphql, repository does not exist or may require
'docker login': denied: requested access to the resource is denied
Here's the secret generated by
kubectl create secret generic regcred \
--from-file=.dockerconfigjson=<pathtofile>.docker/config.json \
--type=kubernetes.io/dockerconfigjson
And here's the secret yaml file I have created
apiVersion: v1
data:
.dockerconfigjson: xxx9tRXpNakZCSTBBaFFRPT0iCgkJfQoJfQp9
kind: Secret
metadata:
name: node-graphql-secret
uid: xxx-2e18-44eb-9719-xxx
type: kubernetes.io/dockerconfigjson
Did anyone try to pull a private docker image into Kubernetes using a secret? Any kind of help would be appreciated. Thank you!
I managed to add the secrets config in the following steps.
First, you need to login to docker hub using:
docker login
Next, you create a k8s secret running:
kubectl create secret generic <your-secret-name>\\n --from-file=.dockerconfigjson=<pathtoyourdockerconfigfile>.docker/config.json \\n --type=kubernetes.io/dockerconfigjson
And then get the secret in yaml format
kubectl get secret -o yaml
It should look like this:
apiVersion: v1
items:
- apiVersion: v1
data:
.dockerconfigjson: xxxewoJImF1dGhzIjogewoJCSJodHRwczovL2luZGV4LmRvY2tl
kind: Secret
metadata:
creationTimestamp: "2022-10-27T23:06:01Z"
name: <your-secret-name>
namespace: default
resourceVersion: "513"
uid: xxxx-0f12-4beb-be41-xxx
type: kubernetes.io/dockerconfigjson
kind: List
metadata:
resourceVersion: ""
And I have copied the content for the secret in the secret yaml file:
apiVersion: v1
data:
.dockerconfigjson: xxxewoJImF1dGhzIjogewoJCSJodHRwczovL2luZGV4LmRvY2tlci
kind: Secret
metadata:
creationTimestamp: "2022-10-27T23:06:01Z"
name: <your-secret-name>
namespace: default
resourceVersion: "513"
uid: xxx-0f12-4beb-be41-xxx
type: kubernetes.io/dockerconfigjson
It works! This is a simple approach to using Secret to pull a private docker image for K8s.
As a side note, to apply the secret, run kubectl apply -f secret.yml
Hope it helps
We have created kubernetes dashboard using below command.
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml
kubectl patch svc -n kubernetes-dashboard kubernetes-dashboard --type='json' -p '[{"op":"replace","path":"/spec/type","value":"NodePort"}]'
created dashboard-adminuser.yaml file like below.
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kubernetes-dashboard
Created ClusterRoleBinding.yaml file like below
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kubernetes-dashboard
And then run the below command at the end we got a token to login dashboard.
kubectl apply -f dashboard-adminuser.yaml
kubectl apply -f ClusterRoleBinding.yaml
kubectl -n kubernetes-dashboard create token admin-user
But the problem is the token which we generated got expired in one hour. We couldn't able to use the same token again, if dashboard logged out.
So can we create a token without expiry or at least minimum 6 months?
What is the command/procedure to create a token for long time use?
And one more thing is that can now we are accessing kubernetes dashboard like below in outside.
https://server_ip_address:PORT_NUMBER
Now we want to open the kubernetes dashboard using our website URL like below and it should login automatically to the dashboard.
https://my-domain-name.com/kubernetes-dashboard/{kubernetes-dashboard-goto-url}
you can set --duration=0s:
--duration=0s:
Requested lifetime of the issued token. The server may return a token with a longer or shorter lifetime.
so this should work
kubectl -n kubernetes-dashboard create token admin-user --duration=times
you can check the further option
kubectl create token --help
kubectl-commands--toke
After play around with token, it seems like the maximum expiration is 720h.
kubectl create token default --duration=488h --output yaml
and the output shows
kind: TokenRequest
metadata:
creationTimestamp: null
spec:
audiences:
- https://container.googleapis.com/v1/projects/test/clusters/test
boundObjectRef: null
expirationSeconds: **172800**
status:
expirationTimestamp: "2022-08-21T12:37:02Z"
token: eyJhbGciOiJSUzI1N....
So the other option is to go with kubeconfig as the dashboard also accepts config.
dashboard-auth-kubeconfig
I'm new to Kubernetes. I need to get token from service account which was created by me. I used kubectl get secrets command and I got "No resources found in default namespace." as return. Then I used kubectl describe serviceaccount deploy-bot-account command to check my service account. It returns me as below.
Name: deploy-bot-account
Namespace: default
Labels: <none>
Annotations: <none>
Image pull secrets: <none>
Mountable secrets: <none>
Tokens: <none>
Events: <none>
How can I fix this issue?
When service account is crated, k8s automatically creates a secrets and maps the same to sa. The secret contains ca.crt, token and namespace that are required for authN against API server.
refer the following commands
# kubectl create serviceaccount sa1
# kubectl get serviceaccount sa1 -oyaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: sa1
namespace: default
secrets:
- name: sa1-token-l2hgs
You can retrieve the token from the secret mapped to the service account as shown below
# kubectl get secret sa1-token-l2hgs -oyaml
apiVersion: v1
data:
ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJd01EUXlNakV4TVRVeE1Wb1hEVE13TURReU1ERXhNVFV4TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBT2lCCk5RTVFPU0Rvdm5IcHQ2MjhkMDZsZ1FJRmpWbGhBb3Q2Uk1TdFFFQ3c3bFdLRnNPUkY4aU1JUDkrdjlJeHFBUEkKNWMrTXkvamNuRWJzMTlUaWEz-NnA0L0pBT25wNm1aSVgrUG1tYU9hS3gzcm13bFZDZHNVQURsdWJHdENhWVNpMQpGMmpBUXRCMkZrTUN2amRqNUdnNnhCTXMrcXU2eDNLQmhKNzl3MEFxNzZFVTBoTkcvS2pCOEd5aVk4b3ZKNStzCmI2LzcwYU53TE54TVU3UjZhV1d2OVJhUmdXYlVPY2RxcWk4WnZtcTZzWGZFTEZqSUZ5SS9GeHd6SWVBalNwRjEKc0xsM1dHVXZONkxhNThUdFhrNVFhVmZKc1JDUGF0ZjZVRzRwRVJDQlBZdUx-lMzl4bW1LVk95TEg5ditsZkVjVApVcng5Qk9LYmQ4VUZrbXdpVSs4Q0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFKMkhUMVFvbkswWnFJa0kwUUJDcUJUblRoT0cKeE56ZURSalVSMEpRZTFLT2N1eStZMWhwTVpYOTFIT3NjYTk0RlNiMkhOZy9MVGkwdnB1bWFGT2d1SE9ncndPOQpIVXZVRFZPTDlFazF5SElLUzBCRHdrWDR5WElMajZCOHB1Wm1FTkZlQ0cyQ1I5anpBVzY5ei9CalVYclFGVSt3ClE2OE9YSEUybzFJK3VoNzBiNzhvclRaaC9hVUhybVAycXllakM2dUREMEt1QzlZcGRjNmVna2U3SkdXazJKb3oKYm5OV0NHWklEUjF1VFBiRksxalN5dTlVT1MyZ1dzQ1BQZS8vZ2JqUURmUmpyTjJldmt2RWpBQWF0OEpsd1FDeApnc3ZlTEtCaTRDZzlPZDJEdWphVmxtR2YwUVpXR1FmMFZGaEFlMzIxWE5hajJNL2lhUXhzT3FwZzJ2Zz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
namespace: ZGVmYXVsdA==
token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNklpSjkuZXlKcGMzTWlPaUpyZFdKbGNtNWxkR1Z6TDNObGNuWnBZMlZoWTJOdmRXNTBJaXdpYTNWaVpYSnVaW-FJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5dVlXMWxjM0JoWTJVaU9pSmtaV1poZFd4MElpd2lhM1ZpWlhKdVpYUmxjeTVwYnk5elpYSjJhV05sWVdOamIzVnVkQzl6WldOeVpYUXVibUZ0WlNJNkluTmhNUzEwYjJ0bGJpMXNNbWhuY3lJc0ltdDFZbVZ5Ym1WMFpYTXVhVzh2YzJWeWRtbGpaV0ZqWTI5MWJuUXZjMlZ5ZG1salpTMWhZMk52ZFc1MExtNWhiV1VpT2lKellURWlMQ0pyZFdKbGNtNWxkR1Z6TG1sdkwzTmxjblpwWTJWaFkyTnZkVzUwTDNObGNuWnBZMlV0WVdOamIzVnVkQzUxYVdRaU9pSXhaRFUyWW1Vd09DMDRORGt4TFRFeFpXRXRPV0ppWWkwd01qUXlZV014TVRBd01UVWlMQ0p6ZFdJaU9pSnplWE4wWlcwNmMyVnlkbWxqWldGalkyOT-FiblE2WkdWbVlYVnNkRHB6WVRFaWZRLmFtdGFORHZUNE9DUlJjZVNpTUE0WjhxaExIeTVOMUlfSG12cTBPWDdvV3RVNzdEWl9wMnVTVm13Wnlqdm1DVFB0T01acUhKZ29BX0puYUphWmlIU3IyaGh3Y2pTN2VPX3dhMF8tamk0ZXFfa0wxVzVNMDVFSG1YZFlTNzdib-DAtZ29jTldxT2RORVhpX1VBRWZLR0RwMU1LeFpFdlBjamRkdDRGWVlBSmJ5LWRqdXNhRjhfTkJEclhJVUNnTzNLUUlMeHZtZjZPY2VDeXYwR3l4ajR4SWRPRTRSSzZabzlzSW5qY0lWTmRvVm85Y3o5UzlvaGExNXdrMWl2VDgwRnBqU3dnUUQ0OTFqdEljdFppUkJBQzIxZkhYMU5scENaQTdIb3Zvck5Yem9maGpmUG03V0xRUUYyQjc4ZkktUEhqMHM2RnNpMmI0NUpzZzFJTTdXWU50UQ==
kind: Secret
metadata:
annotations:
kubernetes.io/service-account.name: sa1
kubernetes.io/service-account.uid: 1d56be08-8491-11ea-9bbb-0242ac110015
name: sa1-token-l2hgs
namespace: default
type: kubernetes.io/service-account-token
So I am looking to set up cert-manager on GKE using google clouddns. It seems like a lot of the older questions on SO that have been asked are using http01 instead of dns01. I want to make sure everything is correct so I don't get rate limited.
here is my issuer.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: engineering#company.com
privateKeySecretRef:
name: letsencrypt-staging
solvers:
- dns01:
clouddns:
project: MY-GCP_PROJECT
# This is the secret used to access the service account
serviceAccountSecretRef:
name: clouddns-dns01-solver-svc-acct
key: key.json
here is my certificate.yaml
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: my-website
namespace: default
spec:
secretName: my-website-tls
issuerRef:
# The issuer created previously
name: letsencrypt-staging
dnsNames:
- my.website.com
I ran these commands to get everything configured:
kubectx my-cluster
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.1/cert-manager.yaml
kubectl get pods --namespace cert-manager
gcloud iam service-accounts create dns01-solver --display-name "dns01-solver"
gcloud projects add-iam-policy-binding $PROJECT_ID --member serviceAccount:dns01-solver#$PROJECT_ID.iam.gserviceaccount.com --role roles/dns.admin
gcloud iam service-accounts keys create key.json --iam-account dns01-solver#$PROJECT_ID.iam.gserviceaccount.com
kubectl create secret generic clouddns-dns01-solver-svc-acct --from-file=key.json
kubectl apply -f issuer.yaml
kubectl apply -f certificate.yaml
here is the output from kubectl describe certificaterequests
Name: my-certificaterequests
Namespace: default
Labels: <none>
Annotations: cert-manager.io/certificate-name: my-website
cert-manager.io/private-key-secret-name: my-website-tls
kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"cert-manager.io/v1alpha2","kind":"Certificate","metadata":{"annotations":{},"name":"my-cluster","namespace":"default...
API Version: cert-manager.io/v1alpha3
Kind: CertificateRequest
Metadata:
Creation Timestamp: 2020-06-28T00:05:55Z
Generation: 1
Owner References:
API Version: cert-manager.io/v1alpha2
Block Owner Deletion: true
Controller: true
Kind: Certificate
Name: my-cluster
UID: 81efe2fd-5f58-4c84-ba25-dd9bc63b032a
Resource Version: 192470614
Self Link: /apis/cert-manager.io/v1alpha3/namespaces/default/certificaterequests/my-certificaterequests
UID: 8a0c3e2d-c48e-4cda-9c70-b8dcfe94f14c
Spec:
Csr: ...
Issuer Ref:
Name: letsencrypt-staging
Status:
Certificate: ...
Conditions:
Last Transition Time: 2020-06-28T00:07:51Z
Message: Certificate fetched from issuer successfully
Reason: Issued
Status: True
Type: Ready
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal OrderCreated 16m cert-manager Created Order resource default/my-certificaterequests-484284207
Normal CertificateIssued 14m cert-manager Certificate fetched from issuer successfully
I see the secret kubectl get secret my-website-tls
NAME TYPE DATA AGE
my-website-tls kubernetes.io/tls 3 18m
Does that means everything worked and I should try it in prod? What worries me is that I didn't see any DNS records change in my cloud console.
In addition I wanted to confirm:
How would I change the certificate to be for a wildcard *.company.com?
If in fact I am ready for prod and will get the cert, I just need to updated the secret name in my ingress deployment to redeploy?
Any insight would be greatly appreciated. Thanks
I answered you on Slack already. And you would change the name by changing the value in the dnsNames section of the Certificate or the spec.tls.*.hosts if using ingress-shim, you just include the wildcard name exactly as you showed it.