| Author |
Message
|
| Ross |
 Posted: Wed Dec 21, 2011 4:31 am Post subject: Allow Start/Stop Flow &EG, but restrict Deploy. |
 |
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
Hi,
I am setting up ACLs for a broker on V6.1 (on AIX) and I want to allow developers to stop and start flows and execution groups, but I don't want them to be able to deploy or delete flows/bar files.
This access is bundled, so DEPLOY access will allow it all, and VIEW access will block it all.
Is there any way of separating this access out?
I can't find any appropriate search results for this.
Thanks,
Ross. |
|
| Back to top |
|
 |
| vmcgloin |
| Posted: Wed Dec 21, 2011 4:37 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Actually I think you would find you need full control to allow them to start & stop the execution group.
start/stop flow is effectively a deploy in 6.1 so I think as you have found you cannot separate out those permissions.
You might wish to allow them access to a wrapper script that uses a different userid to do what they need to be able to do without giving access you do not want to give?
Or trust your developers and audit sufficiently so that they can be held to account when they do something they have been told/asked not to? |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 4:56 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
You're right, DEPLOY is just flows. My mistake. This was the best compromise I could see, just flows, but not execution groups!
We may have to go down the route of trusting developers  , or just allowing a small number D or F access, and V for the rest.
Not really looking to go down the route of a wrapper script, but I'll have a look into it.
Thanks for the information. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 5:00 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| Is there any way to use file security to do this? |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Dec 21, 2011 6:00 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
Even if you played with file permissions e.g. for mqsistartmsgflows in 6.1:
| Quote: |
| On all supported platforms, the user ID that runs this command must have sufficient authority defined in the access control list defined to the Configuration Manager. The permissions required are the same as the permission required to do the equivalent function in the Message Broker Toolkit |
Also note that whatever you do to set all this up can be rethought when you upgrade to V7 as access is then controlled at the MQ level rather than configmgr ACL's. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 21, 2011 6:02 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Developers should have no access to any thing other than their own PC. Build Engineer(s) should deploy, stop and start EGs and Brokers.
Allowing developers to impact your DevInt, Test, or Prod environments is the quickest way to compromise the integrity of your software engineering process.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 21, 2011 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Developers should have no access to any thing other than their own PC. Build Engineer(s) should deploy, stop and start EGs and Brokers. |
We've been here. A lot.
What's going to be the expedient solution here? Develop a solution that's more secure than the OP's current model, or convince the OP's maagement to employ / train some Build Engineers, build an automated deploy & control system with full audit and dancing ACLs?
It's Xmas. Give the crusade a rest.
| lancelotlinc wrote: |
| Allowing developers to impact your DevInt, Test, or Prod environments is the quickest way to compromise the integrity of your software engineering process. |
Keeping Developers out of the DevInt environment (assuming you're lucky enough to have one) can get you some funny looks. Especially if you're one of those heretical sites that isn't performing software engineering but is instead writing code to support a business process.
(And before you say they're the same thing, look down from your tower at the huge mass of drudges whose management don't care that much about process, software, or anything except hitting time & budget targets with something the users will sign off on. Then pity us.)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 6:20 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
All fair comments.
This is for project specific dev streams, and we do want to allow them some flexibility, rather than hounding the MQ admins all day. We do have source controlled code deployment, hence the need to prevent random deploys. Everything is much tighter in latter stages of test.
Thanks for the views. We'll consider whether to allow them access and some trust, or lock it down and dedicate more of our time to developer support. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 6:22 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| vmcgloin wrote: |
Even if you played with file permissions e.g. for mqsistartmsgflows in 6.1:
| Quote: |
| On all supported platforms, the user ID that runs this command must have sufficient authority defined in the access control list defined to the Configuration Manager. The permissions required are the same as the permission required to do the equivalent function in the Message Broker Toolkit |
Also note that whatever you do to set all this up can be rethought when you upgrade to V7 as access is then controlled at the MQ level rather than configmgr ACL's. |
We have V7 installations too, so working on the OAM for this also, which is slightly better than ACL, but some similar issues too. I'm sure this has been discussed at length.
Thanks for your time. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 21, 2011 6:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Ross wrote: |
| I'm sure this has been discussed at length. |
My crusading associate (once he's finished grinding his teeth) will be reassured you have automation & tighter controls as you move towards implementation.
The length of this discussion, in all it's facets, sometimes seems infinite. But this does mean there's a wealth of searchable resource in here...
And it's not that my crusading associate is wrong; he's just pragmatism-impaired....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 6:41 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| Always a balancing act between ideals and reality! |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 21, 2011 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Ross wrote: |
| Always a balancing act between ideals and reality! |
Exactly so.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 21, 2011 6:47 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Ross wrote: |
All fair comments.
This is for project specific dev streams, and we do want to allow them some flexibility, rather than hounding the MQ admins all day. We do have source controlled code deployment, hence the need to prevent random deploys. Everything is much tighter in latter stages of test.
Thanks for the views. We'll consider whether to allow them access and some trust, or lock it down and dedicate more of our time to developer support. |
Developers should use Hudson, CruiseControl, or BuildForge to effect environment changes in DevInt. There is no need for humans to do it.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Dec 21, 2011 6:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| Developers should have no access to any thing other than their own PC. Build Engineer(s) should deploy, stop and start EGs and Brokers. |
We've been here. A lot.
What's going to be the expedient solution here? Develop a solution that's more secure than the OP's current model, or convince the OP's maagement to employ / train some Build Engineers, build an automated deploy & control system with full audit and dancing ACLs?
It's Xmas. Give the crusade a rest.
|
Ok.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Ross |
| Posted: Wed Dec 21, 2011 8:45 am Post subject: |
|
|
Centurion
Joined: 15 Jun 2005
Posts: 127
Location: Ireland
|
| lancelotlinc wrote: |
| Ross wrote: |
All fair comments.
This is for project specific dev streams, and we do want to allow them some flexibility, rather than hounding the MQ admins all day. We do have source controlled code deployment, hence the need to prevent random deploys. Everything is much tighter in latter stages of test.
Thanks for the views. We'll consider whether to allow them access and some trust, or lock it down and dedicate more of our time to developer support. |
Developers should use Hudson, CruiseControl, or BuildForge to effect environment changes in DevInt. There is no need for humans to do it. |
We use clearcase. But still have a need to start/stop during testing. |
|
| Back to top |
|
|
|
|
