Kubernetes Secret use base64 encoding (not encryption) for Secret, because it allows Secrets to store binary data.

## GitOps and secrets management strategies
While users are perfectly comfortable with storing configuration in Git, when it comes to sensitive data, they are unwilling to store that data in Git due to security concerns.

### Storing Secrets in Git
The only real acceptable scenarios where Secrets could be stored as is in Git are when the Secrets do not contain any truly sensitive data, such as dev and test environments.

### Baking Secrets into the container image


FROM scratch
COPY ./my-app /my-app
COPY ./credentials.txt /credentials.txt
ENTRYPOINT ["/my-app"]

An advantage of this approach is that it removes Git and even Kubernetes itself from the equation.

However, baking the sensitive data directly into the container image has some very bad drawbacks. Due to the fact that the sensitive data was baked into the image, anyone or anything that has access to the container image (such as via a docker pull), can now trivially copy out and retrieve the Secret.

### Out-of-band management
A second approach for dealing with Secrets in GitOps is to manage Secrets completely out-of-band from GitOps. With this approach, everything except Kubernetes Secrets would be defined in Git and deployed via GitOps.


### External Secrets management systems
Another strategy for dealing with Secrets in GitOps is to use an external Secret management system other than Kubernetes. The application containers themselves retrieve the Secret values dynamically at run-time. A variety of Secret management systems exist.

For example Vault:


### Encrypting Secrets in Git
Since Git is considered unsafe for storing plain-text Secrets, one strategy is to encrypt the sensitive data so that it is safe to store in Git and then decrypt the encrypted data closer to its point of use.


But anyone with access to the encryption key now has the ability to decrypt and gain access to the sensitive data in the manifests.