kubernetes update secrets using imperative commands - kubernetes

I am creating kubernetes secrets using the below command
kubectl create secret generic test-secret --save-config --dry-run=client --from-literal=a=data1 --from-literal=a=data2 -o yaml | kubectl apply -f -
Now, I need to add new literals using kubectl imperative command how to do that??
say eg:
kubectl apply secret generic test-secret --from-literal=c=data3 -o yaml | kubectl apply -f -
but gave the below error
Error: unknown flag: --from-literal
See 'kubectl apply --help' for usage.
error: no objects passed to apply
Any quick help is appreciated

add new literals using kubectl imperative command
When working with imperative commands it typically means that you don't save the change in a place outside the cluster. You can edit a Secret in the cluster directly:
kubectl edit secret test-secret
But if you want to automate your "addition", then you most likely save your Secret another place before applying to the cluster. How to do this depends on how you manage Secrets. One way of doing it is by adding it to e.g. Vault and then have it automatically injected. When working in an automated way, it is easier to practice immutable Secrets, and create new ones instead of mutating - because you typically need to redeploy your app as well, to make sure it uses the new. Using Kustomize with secretGenerator might be a good option if you work with immutable Secrets.

You can use kubectl patch imeperative command
example
root#controlplane:~# kubectl patch secrets test-secret --type='json' -p='[{"op" : "replace" ,"path" : "/data/newkey" ,"value" : "bmV3VmFsCg=="}]'
secret/test-secret patched
root#controlplane:~# kubectl describe secrets test-secret
Name: test-secret
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
a: 5 bytes
b: 5 bytes
newkey: 7 bytes
you need to pass encoded value, to encode/decode the new value of key you can use below command
root#controlplane:~# echo "newValue" | base64
bmV3VmFsdWUK
root#controlplane:~# echo bmV3VmFsdWUK | base64 -d
newValue
another option is to use kubectl edit but if you automate your code you can't use edit option
kubectl edit secret test-secret

Related

Creating secrets from env file configured to a certain namespace

So when creating secrets I often will use:
kubectl create secret generic super-secret --from-env-file=secrets
However, I wanted to move this to a dedicated secrets.yaml file, of kind "Secret" as per the documentation: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#-em-secret-generic-em-
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).
So, I am back to using the kubectl create secret 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?)
You can provide stringData section of a Secret instead of data section. That won't require base64 encoding. Here, is an example:
apiVersion: v1
kind: Secret
metadata:
name: secret-basic-auth
namespace: demo
type: kubernetes.io/basic-auth
stringData:
username: admin
password: t0p-Secret
Ref: https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret
You can use --dry-run and -oyaml flags.
Use this command to generate your secrets.yaml file
kubectl create secret generic super-secret \
--from-env-file=secrets --namespace <your-namespace> \
--dry-run=client -oyaml > secrets.yaml
The above is pretty standard in the k8s community.
Kubectl's standard options include a --namespace or -n option*, which can achieve this with zero fuss:
kubectl create secret generic super-secret --from-env-file=secrets --namespace=whatever_namespace_you want
*This is not included or mentioned in the documentation for creating a secret, explicitly. It's assumed knowledge for that section.

Copy a configmap but with another name in the same namespace (kubernetes/kubectl)

I have a configmap my-config in a namespace and need to make a copy (part of some temporary experimentation) but with another name so I end up with :
my-config
my-config-copy
I can do this with:
kubectl get cm my-config -o yaml > my-config-copy.yaml
edit the name manually followed by:
kubectl create -f my-config-copy.yaml
But is there a way to do it automatically in one line?
I can get some of the way with:
kubectl get cm my-config --export -o yaml | kubectl apply -f -
but I am missing the part with the new name (since names are immutable I know this is not standard behavior).
Also preferably without using export since:
Flag --export has been deprecated, This flag is deprecated and will be removed in future.
Any suggestions?
You can achieve this by combining kubectl's patch and apply functions.
kubectl patch cm source-cm -p '{"metadata":{ "name":"target-cm"}}' --dry-run=client -o yaml | kubectl apply -f -
source-cm and target-cm are the config map names

kubectl : --dry-run is deprecated and can be replaced with --dry-run=client

I have aws-eks cluster and below is my command to replace existing the configuration.
kubectl create configmap flink-config --from-file=./config -o yaml --dry-run | kubectl replace -
but when I run this command. it gives an error like
W1009 17:00:14.998329 323115 helpers.go:553] --dry-run is deprecated and can be replaced with --dry-run=client.
Will it do the same thing If I replace -dry-run to -dry-run=client?
About dry-run=client we learn
--dry-run=client flag to preview the object that would be sent to
your cluster, without really submitting it.
And in the kubernetes API reference we read:
Must be "none", "server", or "client". If client strategy, only print
the object that would be sent, without sending it. If server strategy,
submit server-side request without persisting the resource.
Performing local tests I realized that when I try to replace an existing config object using dry-run=server, the following error occurs. The apiserver told us that already exist a configmap with the name flink-config.
kubectl create configmap flink-config --from-file=./config -o yaml --dry-run=server
Error from server (AlreadyExists): configmaps "flink-config" already exists
However is I try with to use dry-run=client the object is not validated by the apiserver, that is, just by the client, so the yaml is printed to us:
kubectl create configmap flink-config --from-file=./config -o yaml --dry-run=client
apiVersion: v1
data:
config: |
FOO: foo
MYVAR: hello
kind: ConfigMap
metadata:
creationTimestamp: null
name: flink-config
So basically, yes, the dry-run=client it has the same effect than the deprecated dry-run. The equivalent flag for dry-run=server was --server-dry-run and became deprecated in v1.18.

Kubectl create "invalid object"

I am creating namespace using kubectl with yaml. The following is my yaml configuration
apiVersion: v1
kind: Namespace
metadata:
name: "slackishapp"
labels:
name: "slackishapp"
But, when I run kubectl create -f ./slackish-namespace-manifest.yaml, I got an error like the following
error: SchemaError(io.k8s.api.autoscaling.v2beta2.PodsMetricStatus): invalid object doesn't have additional properties.
What goes wrong on my yaml? I am reading about it on the documentation as well. I don't see any difference with my configuration.
There is nothing wrong with your yaml but I suspect you have the wrong version of kubectl.
kubectl needs to be within 1 minor from the cluster you are using as described here.
You can check your versions with
kubectl version
Download the kubectl.exe on https://kubernetes.io/docs/tasks/tools/install-kubectl/#before-you-begin then replace it on Program Files\Docker\Docker\resources\bin if you have docker desktop
Like Andreas Wederbrand said, it is a version problem.
As a workaround, try to create your namespace within imperative mode
kubectl create ns slackishapp && kubectl label ns slackishapp name=slackishapp
And then compare existing yaml with one you have written in order to check what is missing
kubectl get ns slackishapp -o yaml --export

Is there a way to share a configMap in kubernetes between namespaces?

We are using one namespace for the develop environment and one for the staging environment. Inside each one of this namespaces we have several configMaps and secrets but there are a lot of share variables between the two environments so we will like to have a common file for those.
Is there a way to have a base configMap into the default namespace and refer to it using something like:
- envFrom:
- configMapRef:
name: default.base-config-map
If this is not possible, is there no other way other than duplicate the variables through namespaces?
Kubernetes 1.13 and earlier
They cannot be shared, because they cannot be accessed from a pods outside of its namespace. Names of resources need to be unique within a namespace, but not across namespaces.
Workaround it is to copy it over.
Copy secrets between namespaces
kubectl get secret <secret-name> --namespace=<source-namespace> --export -o yaml \
| kubectl apply --namespace=<destination-namespace> -f -
Copy configmaps between namespaces
kubectl get configmap <configmap-name>  --namespace=<source-namespace> --export -o yaml \
| kubectl apply --namespace=<destination-namespace> -f -
Kubernetes 1.14+
The --export flag was deprecated in 1.14
Instead following command can be used:
kubectl get secret <secret-name> --namespace=<source-namespace>  -o yaml \
| sed 's/namespace: <from-namespace>/namespace: <to-namespace>/' \
| kubectl create -f -
If someone still see a need for the flag, there’s an export script written by #zoidbergwill.
Please use the following command to copy from one namespace to another
kubectl get configmap <configmap-name> -n <source-namespace> -o yaml | sed 's/namespace: <source-namespace>/namespace: <dest-namespace>/' | kubectl create -f -
kubectl get secret <secret-name> -n <source-namespace> -o yaml | sed 's/namespace: <source-namespace>/namespace: <dest-namespace>/' | kubectl create -f -