Configuration Suggestions on CCE Secret Security
Currently, CCE has configured static encryption for secret resources. The secrets created by users will be encrypted and stored in etcd of the CCE cluster. Secrets can be used in two modes: environment variable and file mounting. No matter which mode is used, CCE still transfers the configured data to users. Therefore, it is recommended that:
- Do not record sensitive information in logs.
- For the secret that uses the file mounting mode, the default file permission mapped in the container is 0644. Configure stricter permissions for the file. For example:
apiversion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" volumes: - name: foo secret: secretName: mysecret defaultMode: 256
In defaultMode: 256, 256 is a decimal number, which corresponds to the octal number 0400.
- When the file mounting mode is used, configure the secret file name to hide the file in the container.
apiVersion: v1 kind: Secret metadata: name: dotfile-secret data: .secret-file: dmFsdWUtMg0KDQo= --- apiVersion: v1 kind: Pod metadata: name: secret-dotfiles-pod spec: volumes: - name: secret-volume secret: secretName: dotfile-secret containers: - name: dotfile-test-container image: k8s.gcr.io/busybox command: - ls - "-1" - "/etc/secret-volume" volumeMounts: - name: secret-volume readOnly: true mountPath: "/etc/secret-volume"
In this way, .secret-file cannot be seen by running ls -l in the /etc/secret-volume/ directory, but can be viewed by running ls -al.
- Encrypt sensitive information before creating a secret and decrypt the information when using it.
Using a Bound ServiceAccount Token to Access a Cluster
The secret-based ServiceAccount token does not support expiration time or auto update. In addition, after the mounting pod is deleted, the token is still stored in the secret. Token leakage may incur security risks. A bound ServiceAccount token is recommended for CCE clusters of version 1.23 or later. In this mode, the expiration time can be set and is the same as the pod lifecycle, reducing token leakage risks. Example:
apiVersion: apps/v1 kind: Deployment metadata: name: security-token-example namespace: security-example spec: replicas: 1 selector: matchLabels: app: security-token-example label: security-token-example template: metadata: annotations: seccomp.security.alpha.kubernetes.io/pod: runtime/default labels: app: security-token-example label: security-token-example spec: serviceAccountName: test-sa containers: - image: ... imagePullPolicy: Always name: security-token-example volumes: - name: test-projected projected: defaultMode: 420 sources: - serviceAccountToken: expirationSeconds: 1800 path: token - configMap: items: - key: ca.crt path: ca.crt name: kube-root-ca.crt - downwardAPI: items: - fieldRef: apiVersion: v1 fieldPath: metadata.namespace path: namespace
For details, see Managing Service Accounts.
Using the CCE Secrets Manager for DEW Add-on
The CCE Secrets Manager for DEW add-on (dew-provider) is used to interconnect with DEW. This add-on allows you to mount secrets stored outside a cluster (DEW for storing sensitive information) to pods. In this way, sensitive information can be decoupled from the cluster environment, which prevents information leakage caused by program hardcoding or plaintext configuration. For details, see CCE Secrets Manager for DEW.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot