Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 843687

Summary: authenticate calls from lab machines to beaker-proxy with a signed token unique per recipe
Product: [Retired] Beaker Reporter: Dan Callaghan <dcallagh>
Component: lab controllerAssignee: beaker-dev-list
Status: CLOSED WONTFIX QA Contact: tools-bugs <tools-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 0.9CC: bpeck, cbouchar, stl, tools-bugs, xtian
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: Misc
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 572834 Environment:
Last Closed: 2020-11-19 22:08:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1215894    

Description Dan Callaghan 2012-07-27 04:01:23 UTC 
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 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 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 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ý [poki] 2014-12-03 17:35:26 UTC 
"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 :)