Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 17. Secrets

17.1. Overview
링크 복사

The Secret object type provides a mechanism to hold sensitive information such as passwords, OpenShift Enterprise client config files, dockercfg files, private source repository credentials, etc. Secrets decouple sensitive content from the pods that use it and can be mounted into containers using a volume plug-in or used by the system to perform actions on behalf of a pod. This topic discusses important properties of secrets and provides an overview on how developers can use them.

Example 17.1. YAML Secret Object Definition

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
data:
1 

  username: "dmFsdWUtMQ0K"
  password: "dmFsdWUtMg0KDQo="
Copy to Clipboard Toggle word wrap
1
The allowable format for the keys in the data field must meet the guidelines in the DNS_SUBDOMAIN value in the Kubernetes identifiers glossary.

17.2. Properties of Secrets
링크 복사

Key properties include:

  • Secret data can be referenced independently from its definition.
  • Secret data never comes to rest on the node. Volumes are backed by temporary file-storage facilities (tmpfs).
  • Secret data can be shared within a namespace.

17.2.1. Secrets and the Pod Lifecycle
링크 복사

A secret must be created before the pods that depend on it.

Containers read the secret from the files. If a secret is expected to be stored in an environment variable, then you must modify the image to populate the environment variable from the file before running the main program.

Once a pod is created, its secret volumes do not change, even if the secret resource is modified. To change the secret used, the original pod must be deleted, and a new pod (perhaps with an identical PodSpec) must be created. An exception to this is when a node is rebooted and the secret data must be re-read from the API server. Updating a secret follows the same workflow as deploying a new container image. The kubectl rollingupdate command can be used.

The resourceVersion value in a secret is not specified when it is referenced. Therefore, if a secret is updated at the same time as pods are starting, then the version of the secret will be used for the pod will not be defined.

Note

Currently, it is not possible to check the resource version of a secret object that was used when a pod was created. It is planned that pods will report this information, so that a controller could restart ones using a old resourceVersion. In the interim, do not update the data of existing secrets, but create new ones with distinct names.

17.3. Creating and Using Secrets
링크 복사

When creating secrets:

  • Create a secret object with secret data
  • Create a pod with a volume of type secret and a container to mount the volume
  • Update the pod’s service account to allow the reference to the secret.

17.3.1. Creating Secrets
링크 복사

To create a secret object, use the following command, where the JSON file is a predefined secret: 

$ oc create -f secret.json
Copy to Clipboard Toggle word wrap

17.3.2. Secrets in Volumes and Environment Variables
링크 복사

See examples of YAML files with secret data.

After you create a secret, you can:

  1. Create the pod to reference your secret: 

    $ oc create -f <your_yaml_file>.yaml
    Copy to Clipboard Toggle word wrap

  2. Get the logs: 

    $ oc logs secret-example-pod
    Copy to Clipboard Toggle word wrap

  3. Delete the pod: 

    $ oc delete pod secret-example-pod
    Copy to Clipboard Toggle word wrap

17.3.3. Image Pull Secrets
링크 복사

See Using Image Pull Secrets for more information.

17.3.4. Source Clone Secrets
링크 복사

See Using Private Repositories for Builds for more information.

17.4. Restrictions
링크 복사

To use a secret, a pod needs to reference the secret. A secret can be used with a pod in two ways: either as files in a volume mounted on one or more of its containers, or used by kubelet when pulling images for the pod.

Volume type secrets write data into the container as a file using the volume mechanism. imagePullSecrets use service accounts for the automatic injection of the secret into all pods in a namespaces.

When a template contains a secret definition, the only way for the template to use the provided secret is to ensure that the secret volume sources are validated and that the specified object reference actually points to an object of type Secret. Therefore, a secret needs to be created before any pods that depend on it. The most effective way to ensure this is to have it get injected automatically through the use of a service account.

Secret API objects reside in a namespace. They can only be referenced by pods in that same namespace.

Individual secrets are limited to 1MB in size. This is to discourage the creation of large secrets that would exhaust apiserver and kubelet memory. However, creation of a number of smaller secrets could also exhaust memory.

17.4.1. Secret Data Keys
링크 복사

Secret keys must be in a DNS subdomain.

17.5. Examples
링크 복사

Example 17.2. YAML Secret That Will Create Four Files

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: dmFsdWUtMQ0K
1 

  password: dmFsdWUtMQ0KDQo=
2 

stringData:
  hostname: myapp.mydomain.com
3 

  secret.properties: |-
4 

    property1=valueA
    property2=valueB
Copy to Clipboard Toggle word wrap
1
File contains decoded values.
2
File contains decoded values.
3
File contains the provided string.
4
File contains the provided data.

Example 17.3. YAML of a Pod Populating Files in a Volume with Secret Data

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
      volumeMounts:
          # name must match the volume name below
          - name: secret-volume
            mountPath: /etc/secret-volume
            readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret
  restartPolicy: Never
Copy to Clipboard Toggle word wrap

Example 17.4. YAML of a Pod Populating Environment Variables with Secret Data

apiVersion: v1
kind: Pod
metadata:
  name: secret-example-pod
spec:
  containers:
    - name: secret-test-container
      image: busybox
      command: [ "/bin/sh", "-c", "export" ]
      env:
        - name: TEST_SECRET_USERNAME_ENV_VAR
          valueFrom:
            secretKeyRef:
              name: test-secret
              key: username
  restartPolicy: Never
Copy to Clipboard Toggle word wrap

17.6. Troubleshooting
링크 복사

Expand
Table 17.1. Troubleshooting Guidance for Secrets
IssueResolution

A service certificate generation fails with (service’s service.alpha.openshift.io/serving-cert-generation-error annotation contains): 

secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
Copy to Clipboard Toggle word wrap

The service that generated the ceritiface no longer exists (has different serviceUID). You must force certificates regeneration by removing the old secret, and clearing following annotations on the service service.alpha.openshift.io/serving-cert-generation-error, service.alpha.openshift.io/serving-cert-generation-error-num: 

$ oc delete secret <secret_name>
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.alpha.openshift.io/serving-cert-generation-error-num-
Copy to Clipboard Toggle word wrap
Note

The command removing annotation has a - after the annotation name to be removed.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat