The point is that in Kubernetes, the secret allows you to protect your password (what you want to do by encrypting it) by controlling the access to the secret, instead of by encrypting it.

There are several mechanisms for it:

• Secrets can only by accessed by those of their very same namespace.
• Secrets have permissions as any other file, so you choose who has access to it.
• They are only sent to pods whenever required, not before.
• They're not written in local disk storage.

That said, in case something goes wrong, solutions as Sealed Secrets created by Bitnami or others solutions (see Mokrecov answer) have arisen to give even more robustness to the matter, just in case someone undesired gained access to your secret.

base64 is encoding, not encryption, it allows you to simply encode information in a convenient way.

The data that you encode may contain many unrecognized characters, line feeds, etc., so it is convenient to encode them.

In kubernetes, you can enable encryption using this instruction.

But kubernetes should not be the only source of truth, rather kubernetes loads these secrets from an external vault that you need to select, such as hashicorp's vault, as indicated in the comments.

In addition to hashicorp vault, there are various ways to store secrets in git:

• Helm secrets
• Kamus
• Sealed secrets
• git-crypt

You may also be interested in the kubesec project, which can be used to analyze kubernetes resources for security risks.