suggested this on March 22, 2012 07:07 AM
Currently, anyone with access to deploy has full access to all dashboard features. It would be much more secure if it were possible to limit, by user, what access they had (e.g. deploy only).
Thank you for this feedback. We've heard this request several times and I've confirmed it's already in the backlog. I have noted the additional request and we'll update this ticket when the feature is prioritized.
For us, it would be much more useful to limit users by environment than the access type. For instance, if I could give many people access to the account and the staging environments in them so they can deploy and test at will, but provide no access for most users to production. That way we can control production without impacting rapid delivery to staging systems.
We too need something like Dan has listed. Its not a good idea to give permission to production app to everyone
Since this feature doesn't exist yet, I'm setting up a staging account and a production account to isolate the production services. When this proposed feature goes live, will I be able to merge these accounts into one to take advantage of the permissions system?
I have added this item to our internal roadmap discussion. Will report back with status.
Any update on this by chance? We need this much worse every week as our team grows.
We (Ryan Gurney and I) have put this as a candidate for inclusion onto the development roadmap. We will be discussing it with the Product organization over the next 2 weeks. I will report back after that.
Product Manager, Engine Yard Cloud & Engine Yard Services
This would be a great feature. I'd like to able to give users deploy access to a staging environment but restrict production.
Has there been any updates on this feature after your Product organization meeting? This would be a great feature for us as we review our security policies and determine how we are going to allow our teams access to Engine Yard for various tasks.
Seriously... we are totally desperate for this feature, I would think any reasonably good sized team that runs both production and stage on you guys would be. Any update?
This has been placed on our Engineering work plan. I will update this as soon as there is something for you to test out.
I am also in need of this feature! Glad to hear it is in the works.
We also have a growing team of developers and would benefit greatly from being able to deploy to staging and test at will, while keeping production systems secure.
Is there any update on this? An ETA perhaps?
This is still on the Roadmap and being planned. When work begins on this feature, I'll update this ticket with a clearer ETA.
Any news on this feature?
There is no news on this feature at this time - still something we are planning to add. Thanks!
EY Business Team
This feature was asked more one and a half years ago and it does surprise me that it has not been launched yet. I think you can do a better job that this. Is there any expedited route that can be followed. I am ready to escalate it.
I feel this is a very basic feature that should be in EY.
Thank you all for elevating this feature within the forums!
I will be owning this project, and am currently in the requirements phase. This is a project we plan to do.
Please let me know if there are any specifics around the controls you want; we're probably going to take a phased approach at first, with more granular controls in the pipeline for later on.
I'm thinking of having the ability to mark environment with a flag "Use extra-caution when deploying" which will basically throw up alert dialogs in the UI and some yes/no kind of prompts thru CLI when triggering deployments.
What are you thinking about this feature?
Hi Tushar -
That functionality is included in our current UI revamp, which will be rolling out over the next few months.
For this feature I'm thinking more along the lines of access control - i.e., ability to limit users per environment (step 1), then by more granular controls as customers need them (only certain people are able to deploy to these things; some people have read only access?; etc).
Having the ability to grant full/no access to users per environment is a great first step.
More granular access control along these lines would serve our use case:
* dashboard and ssh access control: some users can only access dashboard, others can ssh into the instances.
* deploy, start / terminate instances, change environment attributes, apply stack upgrades. These would work either as on/off for every permission, or in a layered access approach.
Your step 1, ability to limit users per environment, is exactly what we need. We don't have a need for anything more granular than that at this time.
Another thing that would be useful is managing ssh access and user accounts on the servers. This first starts by changing it so there are no shared accounts that can ssh into the servers (shared ssh account is often seen as a security issue). So doing away with sshing in as the deploy user. Then providing a way to manage individual keys and individual user accounts, such that all activity on a server can be traced back to the individual user who executed the command. This would likely take a lot more work to make happen but worth thinking about.
Limiting user access per environment is fairly basic, essential to many customers, and would suffice most use cases. Other advanced Role-based access control features can be gradually rolled-out.
+1. Justification, two words: SOX Compliance.
We have this out in EA now! You can enable it on your account. Please let me know how it works for you!
The docs are here: https://support.cloud.engineyard.com/entries/30141896-Use-Access-Co...
Support Ticket System by Zendesk