In deployment.yaml file, we don't add username and password but refer them using secret. This way,the username/password don't get stored in code repositories. In secret.yaml, the username and password are encoded in base64 (which can be decoded). From best practice persepective, doesn't secret.yaml also get source-controlled somewhere (thereby also storing the username/password in version control). If so, what is the benefit of using Secret ?
Good one. Some time ago I already answered Kubernetes secret is really secret? question, check there all the info.
If you configure the secret through a manifest (JSON or YAML) file which has the secret data encoded as base64, sharing this file or checking it in to a source repository means the secret is compromised. Base64 encoding is not an encryption method and is considered the same as plain text.
As you said, secrets are not encrypted but only base64 encoded. Where secrets really add value is that they allow you to keep your passwords, keys, tokens out of your codebase/git repos. If you push your code to Github, you will not be pushing your secrets there. For this reason they are called secrets and add a layer of safety.
However, if someone gets access to your cluster, secrets will be mere plaintext to them.
The recommended way to store the secrets is to use a vault.
https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar
There are a few aspects to be considered when keeping k8s secrets secret.
There's the configuration option --encryption-provider-config, which instructs the api server whether and how to encrypt data in etcd. There's lots more in the docs.
Role Based Access Control is one authz possibility for k8s. Using it, access to secrets can be restricted, so not every user or service account can see secrets, already existing in the cluster, think of kubectl get secret others-secret -n some-ns -o yaml. With RBAC you can create roles with specific sets of permissions - allowing or not access to secrets per namespace - and then assign those roles to users, groups or even service accounts, as you see fit.
3.1 Encryption
There are quite a few tools allowing for encryption of files with sensitive data, which would allow you to commit the file with the secrets to a version control system, if that's what you need. A simpler one would be mozilla SOPS and one somewhat sophisticated and complex might be Vault for example. Whichever it is, it would definitely be nice if not necessary, to be possible to easily integrate it in any delivery pipeline.
3.2 Don't store secrets manifests An alternative approach to the above would be to not store any files with secrets. Create the secret and with regular cluster backups (tools like velero for instance) you should have nothing to worry about.