Bug 843687 - authenticate calls from lab machines to beaker-proxy with a signed token unique per recipe
authenticate calls from lab machines to beaker-proxy with a signed token uniq...
Status: NEW
Product: Beaker
Classification: Community
Component: lab controller (Show other bugs)
0.9
All Linux
medium Severity unspecified (vote)
: ---
: ---
Assigned To: Dan Callaghan
tools-bugs
Misc
: FutureFeature, Triaged
Depends On:
Blocks: 1215894
  Show dependency treegraph
 
Reported: 2012-07-27 00:01 EDT by Dan Callaghan
Modified: 2016-06-08 23:56 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 572834
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Callaghan 2012-07-27 00:01:23 EDT
This bug is cloned from 572834, for implementing the signed-token-based authentication for lab machines that was originally discussed on that bug. An edited copy of the original comments follows.

+++ This bug was initially created as a clone of Bug #572834 +++

--- Additional comment from bpeck@redhat.com on 2011-02-23 05:06:29 EST ---

Power control should be possible but NMI would need support in cobbler. 
Currently cobbler only supports power control.

This feature should be restricted to only work on other recipes in the same
recipeset.

For example:

Job 1:
 RecipeSet 2
   Recipe 3
 RecipeSet 4
   Recipe 5
   Recipe 6

Recipe5 should be allowed to power cycle the host used in Recipe 6, but Recipe
3 should not be allowed to power cycle either Recipe5 or 6 since its outside of
the recipeSet.

--- Additional comment from dcallagh@redhat.com on 2012-07-20 13:11:12 EST ---

(In reply to comment #6)
> I was thinking it might be worth
> while to generate a uuid in the future and use that instead of a recipe id. 
> This would make it very hard to guess.

This is a nice idea. Maybe better than just a UUID (which we have to store somewhere) might be some kind of signed token generated using itsdangerous:

http://packages.python.org/itsdangerous/

--- Additional comment from bpeck@redhat.com on 2012-07-20 23:38:59 EST ---

I like that very much!!  We should think about how we could add this to all the proxy methods.
Comment 1 Jan Pokorný 2014-12-03 12:35:26 EST
"signed-token-based authentication" seems to (vaguely) resemble
idea sketched at [bug 1169007 comment 0]:

> Restriction on "only fellow nodes in the same task can be fenced"
> could be for the sake of simplicity implemented by common knowledge
> of some hash (key) that would have to be included in the actual
> fencing request.

+ adding "such hash could be exported automatically as an env. variable
  to the machines involved in the particular job"


I was considering a scenario of turning unrelated machine of
*by accident*, which I would really prefer to be prevented
rather than having to explain someone else that, e.g., cluster
configuration conversion utility had a bug in it :)

Note You need to log in before you can comment on or make changes to this bug.