docs: add secret management proposal

docs/design/secret_management.md

@@ -0,0 +1,44 @@
+## Secret Management with Kusion
+
+### Motivation
+
+A secret is any piece of sensitive information that must be kept confidential and protected from unauthorized access, this includes passwords, API keys, TLS certificates, tokens, or other credentials. Secret management is a critical aspect of managing any application or infrastructure, therefore Kusion must provide out-of-the-box support. This proposal outlines the method and workflow of How Kusion implement basic secret management.
+
+### Principle
+
+* Perfect security is impossible, the deeper down the rabbit hole, the greater cost you have to pay, therefore we have to make trade-offs and prioritize the most likely scenarios.
+* Keeping secrets outside of Git is especially important for future-proofing, even encrypted secrets are not recommended to check into Git.
+* Better not allow application developers to access cloud secret managers directly, in favor of lower cogntive load and simplify permission management.
+* Support popular cloud native secrets manager, e.g AWS Secrets Manager, Azure Key Vault, Hashicorp Vault, and no need to install additional operators.
+
+### Secret Store
+
+To support popular cloud secret managers, we need to have multiple secret store. We could define a simple interface along the lines of: 
+
+```Go
+// SecretStore is an interface that must be implemented to integrate with
+// various popular cloud native secret managers, e.g. Hashicorp Vault
+type SecretStore interface {
+	// CreateSecret calls external cloud secret manager to store secret information.
+	CreateSecret(key string, value string) error
+	// GetSecret retrieves plain secret information from external cloud secret manager.
+	GetSecret(key string) (string, error)
+}
+```
+
+and different secret stores just need to implement this interface.
+
+### The Workflow
+
+1. During the environmental initialization phase, platform team setup the target secret store, including necessary credentials info to access secret store.
+2. The application developers specify the ref sources of sensitive information that the workload depends on, as well as how the workload consumes this sensitive information, within the configuration code.
+3. Once configuration code submit, the Kusion engine fetchs secrets from target secret store and creates corresponding Kubernetes secrets.
+4. Application process consume Kubernetes secrets during runtime.
+
+### References
+
+1. [https://spacelift.io/blog/terraform-secrets](https://spacelift.io/blog/terraform-secrets) -- Terraform
+2. [https://www.pulumi.com/docs/concepts/secrets/](https://www.pulumi.com/docs/concepts/secrets/) -- Pulumi
+3. [https://developer.hashicorp.com/vault/tutorials/kubernetes/vault-secrets-operator](https://developer.hashicorp.com/vault/tutorials/kubernetes/vault-secrets-operator) -- Vault Secret Operator
+4. [https://sharonsahadevan.medium.com/kubernetes-secret-management-a-comprehensive-guide-with-aws-secrets-manager-bdebbd70d7b1](https://sharonsahadevan.medium.com/kubernetes-secret-management-a-comprehensive-guide-with-aws-secrets-manager-bdebbd70d7b1) -- AWS Secret Manager
+4. [https://www.macchaffee.com/blog/2022/k8s-secrets/](https://www.macchaffee.com/blog/2022/k8s-secrets/) -- Kubernetes Secrets