[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rhc commands targetting individual gears/nodes

Thx Clayton. Good to know you guys are also thinking about those. Fairly important.
The whole trust thing is always subjective. Even today developers deliver code [without PaaS] and still can do damage but there is a super approval process to get direct access to live boxes. And though empowering the developers is welcome there are certain doors still very difficult to get open. This is unfortunately a reality not only in our company but elsewhere [non startup companies]. So, some sort of segmentation/balance is needed.


From: Clayton Coleman <ccoleman redhat com>
To: meghdoot bhattacharya <meghdoot_b yahoo com>
Cc: dev lists openshift redhat com
Sent: Monday, March 4, 2013 12:40 PM
Subject: Re: rhc commands targetting individual gears/nodes

----- Original Message -----
> Hi,
> Over the years spending my time in application teams, the situation
> would often arise that a funky behavior is happening only in few
> instances in a large pool or maybe Ops have configured honeypot to
> observe behavior in few instances for app troubleshooting.
> Do we have plans where rhc can be used for targeting individual gear
> or maybe all gears in a node but not the entire app itself?

Yes, today it's fairly limited.

> I just noticed in Openshift Online [have to try it in origin] that
> rhc threaddump not supported for scaled apps.

That is correct, it's a limitation that needs to be corrected.

> Does rhc tail aggregate logs from N gear instances. That would be
> waste.

It does not, it uses the head gear.  We would like to make rhc target individual gears if a user so chooses.

> It would be nice to have specific targets for these commands to
> provide more value. Same goes for app start/stop commands also
> having option to have specific targets.

Start/stop gears has been discussed, but the user case is usually that we would start stopped gears.  Stopping started gears was something that hasn't been brought up before.

> This may open up a question why not ssh into those gears and execute
> it locally. As I am explaining the power of Openshift to our app
> teams, the initial consensus though dev has power to push code and
> execute commands remotely, nobody feels comfortable giving them ssh
> access to gears [even with selinux protections]. Requiring regular
> ssh access to LIVE boxes requires very special approval in our
> current organization.

We have discussed splitting SSH access to gears into 3 levels:

  read code
  shell access with read only permissions
  shell access

The caveat here is that certain commands require read access to data today (tail, threaddump, snapshot) and that a solution would need to be put into place.  Also, we haven't really dug into what it would mean to have no shell access but the ability to push code, but the problem is that code that is pushed can do ANYTHING to the gear, so you're not gaining much security by allowing push without shell.  Remember too that anyone who can get shell access can view environment variables, so that's a trust level thing.

> So, the second question is right now anybody having git access means
> they have access to all gears in a scaled app [the way ssh keys are
> copied]. It would be nice to separate git operations permission vs
> access to gears. Is there a way to do it currently?

No way to do it today, but it is in the roadmap.

> Thx
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]