Without significant modifications, is there a way around providing API Keys to launch applications via cloud launch?
For cloudman, there are a lot of explicit calls to the ID and Secret Key in the codebase but we’d like to use the default context if possible. Is there a straightforward way to do this? Will something like this be supported in the future kubernetes version?
Can you clarify your use case a bit further? Do you mean you want to launch additional VMs with the same set of cloud credentials? Using the CloudLaunch commandline interface may be an option in this case or using the ReST API directly.
The Kubernetes version also supports this to some degree. You can create projects and each project can have its own set of applications. Of course, the underlying infrastructure for the k8s cluster is shared among all users. This feature can be tested out by launching a GVL 5.0 alpha. Things are still under development however, although we plan to do another dev release later this year.
Thanks for the quick response. The issue I’m hitting is that my company isn’t comfortable providing or using persistent API keys as these need to be associated with an audit-able account (using a profile role) and these keys need to be rolled on a regular basis.
It’s the AWS equivalent of using --profile for all functionality. The profile roles also include a session token making their access temporary. I’m trying to determine the best course of action working within these constraints and still getting cloudman running. It appears a lot of the core functionality invokes SDK calls directly using only a users account credentials:
CloudBridge accepts session tokens but this is not exposed anywhere in the cloudlaunch API, perhaps this is something you can use to work around this? We would be happy to accept a PR for this.