I think maybe you're conflating job key with task id? The job key is the 4-tuple of the form cluster/role/environment/job-name and is definitely known to users ahead of time (they use it to scheduler their job). The task id, on the other hand, is generated by the scheduler when the task launches. The taskId property is also available via the AssignedTask thrift struct that Bill points out above (see: https://github.com/apache/aurora/blob/master/api/src/main/thrift/org/apache/aurora/gen/api.thrift#L467-L493 ).
On Tue, Jun 7, 2016 at 7:04 AM, Bill Farner <[email protected]> wrote: > The job key is indeed be available to the executor, as it is in > TaskConfig, first used here: > https://github.com/apache/aurora/blob/master/src/main/python/apache/aurora/executor/aurora_executor.py#L257 > > The most common approach I've seen for secrets is out-of-band management > using file system permissions to restrict users (since the executor will > setuid forked user processes). This has some downsides of its own, though. > > > On Tuesday, June 7, 2016, Chris Bannister <[email protected]> wrote: > >> Hi, >> >> Im looking at how to get securely manage secrets for tasks running in a >> multi tenant Aurora cluster. My current thinking is to use Vault to store >> the secrets then have a custom executor which uses something known about >> the task to fetch the secrets from Vault, to do this though I need to have >> a way to know in advance a key for a task to lookup in Vault, which can not >> be set by the users. Ideally this would be the job key, which is set by the >> scheduler, but as far as I can see the executor has no knowledge of the >> scheduler (by design) and that it does not get passed the job key via the >> task.json, or any other metadata. >> >> My question is, is there anyway for a custom executor to find out what >> the tasks job key is that it is launching? Or has anyone found a better >> solution for managing secrets for tasks? >> >> Thanks >> >
