Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document that each user should have separate namespace #18

Open
t1m0thyj opened this issue May 26, 2023 · 2 comments
Open

Document that each user should have separate namespace #18

t1m0thyj opened this issue May 26, 2023 · 2 comments
Labels
bug Something isn't working dev-docs priority-low Legit issue but cosmetic or nice-to-have severity-low Bug that makes the usage of the Zowe less convenient but doesn't impact key use cases

Comments

@t1m0thyj
Copy link
Member

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 zowe/zowe-explorer-vscode#2230 (review)

@t1m0thyj t1m0thyj changed the title Document that each user should use separate namespaces Document that each user should use separate namespace May 26, 2023
@t1m0thyj t1m0thyj added bug Something isn't working documentation Improvements or additions to documentation labels May 26, 2023
@github-actions
Copy link

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.

@t1m0thyj t1m0thyj changed the title Document that each user should use separate namespace Document that each user should have separate namespace May 26, 2023
@rudyflores
Copy link
Collaborator

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).

@JTonda JTonda added dev-docs priority-low Legit issue but cosmetic or nice-to-have severity-low Bug that makes the usage of the Zowe less convenient but doesn't impact key use cases and removed documentation Improvements or additions to documentation labels Jun 6, 2023
@t1m0thyj t1m0thyj moved this to Low Priority in Zowe Explorer for VS Code Dec 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dev-docs priority-low Legit issue but cosmetic or nice-to-have severity-low Bug that makes the usage of the Zowe less convenient but doesn't impact key use cases
Projects
Status: Low Priority
Development

No branches or pull requests

3 participants