Post

1 follower Follow
0
Avatar

Get current user in control task?

Is there a way in a control task to get the user that is currently executing it?

The QBQ (question behind the question) is really that we want a way to define control tasks against a type, but limit who can run which ones.  So if I have CT1 and CT2, both written against an overthere.Host, I may want certain users to be able to run CT1 and CT2, but other users to only be able to run CT1, and even other users only to be able to run CT2.

Is there a way to do that currently?

One way we thought of is within the script that gets executed by a control task, if we could get the current user, then we could see if they belong to some group or something using XLDs API.  But if there were a more native way to do this, that would be great.

Josh Figler

Please sign in to leave a comment.

11 comments

0
Avatar

Hi Josh

> we want a way to define control tasks against a type, but limit who can run which ones.

Have you considered creating an overthere.Host subtype, defining the "restricted" control tasks on that, and putting the hosts in question into a directory on which only the relevant roles have the "execute control task" permission?

That's not the way we would want to address this "properly", I think, but is something that could work for now?

Regards

Andrew

Andrew Phillips 0 votes
0
Avatar

Hi Josh,

 

I introduced the proposed solution of Andrew at some companies and it worked fine, i.e. put CT1 and CT2 in different subdirectories and grant the correct rights.

Levent Tutar 0 votes
0
Avatar

So are you saying that CT1 and CT2 would be defined against different types, and those types would live in different subdirectories, and we would control it at that level using XLD permissions?

As an aside, what about the ability to get the current user running the control task from within a control task.  Is that doable?

Josh Figler 0 votes
0
Avatar

1) They do not have to be of different type. You still write them against overthere.Host as you used to do. If CT1 and CT2 were residing on the same overthere.Host, then you replicate the overthere.Host and also put it in the subdirectory where CT2 should reside. The type is the same but its unique Id is different.

2) Getting the current user running the control task is not doable.

Levent Tutar 0 votes
0
Avatar

I think I'm missing something.

If I have controltask1 and controltask2 written against the type overthere.Host, I don't understand how duplicating my host and putting them into different subdirectories with different permissions would solve this problem?  I still can't say RoleX can run controltask1 only and RoleY can run controltask2 only, can I?  Won't both control tasks be exposed to both Roles because the control task is written against the same type of overthere.Host?

I think that's why I'd need a different (sub) type, like Andrew suggested?

Josh Figler 0 votes
0
Avatar

> I think that's why I'd need a different (sub) type, like Andrew suggested?

That's what I had in mind, yes. So you'd e.g. have overthere.Host with control task A, and overthere.MySpecialHost with control tasks A (inherited from overthere.Host) and B. Then you would put all the overthere.MySpecialHosts into a folder "Special Hosts" and assign control task execute permissions on that folder to your special users only.

Does that make sense? Levent, did you have something else in mind?

Regards

Andrew

Andrew Phillips 0 votes
0
Avatar

Yes, it does make sense.  But it creates different concerns for me.  For example, which set of hosts do I add to an environment to receive actual deployments?  Since they are effectively the same host when executed against, I'd want to designate on of those groups as the one to receive deployments, and the other(s) to not.  I think it creates additional maintenance work, too.

But I'm thinking that is why you likely mentioned _That's not the way we would want to address this "properly", I think, but is something that could work for now?  _And yes, we could probably use this for now.  Or something like it.  Are there any plans to implement a cleaner feature for this?  It seems like other have also requested something similar?

And finally, is not exposing the user executing a control task from within the control task itself a decision made intentionally or something else?  I've needed this for 2 separate things now, so I'm curious if it is worth submitting a feature request?

Josh Figler 0 votes
0
Avatar

I added to pictures to describe my suggestion.

If a user needs to run CT1 and CT2, then he must be member of both roles.

Levent Tutar 0 votes
0
Avatar

Hey Levent -- thanks for the visualization.

If in your images 'Infrastructure/CT1/AHost' and 'Infrastructure/CT2/AHost' are the same type, then all control tasks written against that type will be available to 'AllowedToRunCT1' when operating on 'Infrastructure/CT1/AHost'.  Similarly, all control tasks written against that same type will be available to 'AllowedToRunCT2' when operating on 'Infrastructure/CT2/AHost'.

My use case is that I need 'AllowedToRunCT1' to only be able to run a subset of the control tasks defined for that type.

If I'm understanding you correctly, then I don't think the solutions you've provided satisfies that use case because 'AllowedToRunCT1' can run ANY control task defined for that type of 'Infrastructure/CT1/AHost'

Josh Figler 0 votes
0
Avatar

You are right. In my solution you can run ANY control task that is defined for that type of infrastructure CI.

Levent Tutar 0 votes
0
Avatar

OK, that's good.  I thought I was losing it there for a minute.

Now that you better understand the use case, do any other suggestions come to mind outside of Andrew's thought of sub-typing a CI?

I'm curious if there are any plans to implement a cleaner feature for this in an upcoming release?

Josh Figler 0 votes