ABSTRACT. Selecting a secrets management system for Kubernetes is not a task for beginners, it requires careful consideration of the trade-offs among security controls, operational burden, compliance evidence, performance, and total cost. Kubernetes itself has a native “Secret” object, but unfortunately, the official documentation cautions that “Secrets” are unencrypted by default in the backing store, and that authorisation to create workloads can indirectly expose “Secrets”. Such circumstances motivate stronger controls and, in many environments, the use of the external secret stores. Also, recent research reinforces the finding that “secrets in the platform” are frequent targets of attacks. The studies show widespread Kubernetes misconfigurations, such as hard-coded credentials in manifests, and privilege escalation paths via excessive permissions in cluster add-ons. Both of them can significantly widen the secret-exposure blast radius. Therefore, the goal of this article is to contribute a repeatable methodology for evaluating secrets management systems based on multi-criteria decision analysis. Starting with the definition of an environment profile, moving on to translation of security / operational / compliance / cost objectives into measurable criteria with a 0-5 scoring rubric, eliciting weights (simple ones or analytic hierarchy process), building a decision matrix, and running sensitivity analysis to see how the recommendation changes when priorities shift. The methodology is tested on a baseline set of Kubernetes secret management approaches: hardened Kubernetes Secrets; Sealed Secrets and SOPS (GitOps approaches); External Secrets Operator; Vault; and one commercial operator.