Document that each user should have separate namespace

[t1m0thyj]

In addition, I also noticed that the credentials are stored under a single secret on Google Cloud, and I presume this will also be the case in a local environment. Since the credentials are stored in a way where the Zowe config path is the "key" for the object, @zFernand0 and I quickly discussed a scenario where he could potentially replace my credentials in the secret object:

1. Create a path that matches the file path my credentials are stored under
2. Set the ZOWE_CLI_HOME environment variable to fall under this path (e.g. if my config is /a/b/c/zowe.config.json, ZOWE_CLI_HOME would be /a/b/c).
3. Right click on a session in Zowe Explorer -> "Update Credentials"
4. After entering in the username and password, my stored credentials will be overwritten in the secret object w/ the new credentials provided.

Could we potentially avoid this by generating a unique hash on the user's end, and then chaining that with the file path to make a unique key? Or, could we generate a unique hash and simply use that as the key?

With either proposal, we would have to store the hash/identifier somewhere (such as in the Zowe config itself), but this would prevent someone from intentionally overwriting other user's credentials in the same cluster.

Originally posted by @traeok in https://github.com/zowe/vscode-extension-for-zowe/pull/2230#pullrequestreview-1442485306

[github-actions[bot]]

Thank you for creating a bug report. We will investigate the bug and evaluate its impact on the product. If you haven't already, please ensure you have provided steps to reproduce the bug and as much context as possible.

[rudyflores]

For generating a unique hash, we currently are generating a unique hash, I believe with @zFernand0 we tested this on his end by changing the current context and making a new user, by default when loading a new cluster the default user is being used. In the kubernetes world the default user shouldn't be used. Instead each user should have their own username in the cluster which they log in with. Once logged in with your own user even if in the same namespace this should generate unique keys with your very own secret (although it's recommended to store secrets in their own namespace by good practice).