K
Q

Write to Secret file in pod

6/20/2019

I define a Secret:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
stringData:
  config.yaml: |-
    apiUrl: "https://my.api.com/api/v1"
    username: Administrator
    password: NewPasswdTest11

And then creating volume mount in Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: k8s-webapp-test
  labels:
    name: k8s-webapp-test
    version: 1.0.4
spec:
  replicas: 2
  selector:
    matchLabels:
      name: k8s-webapp-test
      version: 1.0.4
  template:
    metadata:
      labels:
        name: k8s-webapp-test
        version: 1.0.4
    spec:
      nodeSelector:
        kubernetes.io/os: windows
      volumes:
      - name: secret-volume
        secret:
          secretName: string-data-secret
      containers:
      - name: k8s-webapp-test
        image: dockerstore/k8s-webapp-test:1.0.4
        ports:
        - containerPort: 80
        volumeMounts:
        - name: secret-volume
          mountPath: "/secrets"
          readOnly: false

So, after the deployment, I have 2 pods with volume mounts in C:\secrets (I do use Windows nodes). When I try to edit config.yaml that is located in C:\secrets folder, I get following error:

Access to the path 'c:\secrets\config.yaml' is denied.

Although I marked file as readOnly false I cannot write to it. How can I modify the file?

-- eddyuk
kubernetes

Similar Questions

Corda RPC connection on Kubernetes
Helm: variables in values.yaml
How can use static Ip as external-IP at kubernates?
How to simulate nodeNotReady for a node in Kubernetes

2 Answers

2/21/2020

You can create secrets from within a Pod but it seems you need to utilize the Kubernetes REST API to do so: https://kubernetes.io/docs/concepts/overview/kubernetes-api/

-- js80
Source: StackOverflow
6/20/2019

As you can see here it is not possible by intention:

Secret, configMap, downwardAPI and projected volumes will be mounted as read-only volumes. Applications that attempt to write to these volumes will receive read-only filesystem errors. Previously, applications were allowed to make changes to these volumes, but those changes were reverted at an arbitrary interval by the system. Applications should be re-configured to write derived files to another location

You can look into using an init container which maps the secret and then copies it to the desired location where you might be able to modify it.

As an alternative to the init container you might also use a container lifecycle hook i.e. a PostStart-hook which executes immediately after a container is created.

lifecycle:
  postStart:
    exec:
      command:
      - "/bin/sh"
      - "-c"
      - >
        cp -r /secrets ~/secrets;
-- papanito
Source: StackOverflow