Bug 1316598 - [RFE] Satellite 6.2 Remote Execution provider not based on SSH-keys
[RFE] Satellite 6.2 Remote Execution provider not based on SSH-keys
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Remote Execution (Show other bugs)
6.2.0
Unspecified Unspecified
high Severity high (vote)
: Unspecified
: --
Assigned To: satellite6-bugs
: FutureFeature
: 1362309 1393470 (view as bug list)
Depends On:
Blocks: 1353215 1124977
  Show dependency treegraph
 
Reported: 2016-03-10 09:52 EST by Benjamin Chardi
Modified: 2018-05-30 02:50 EDT (History)
20 users (show)

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


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Platform MBU Aha SAT-E-102 None None None 2018-02-17 12:31 EST

  None (edit)
Description Benjamin Chardi 2016-03-10 09:52:45 EST
Dear Friends,

As puppetlabs and Red Hat announced in the following releases of puppet, "puppet kick" will be deprecated and no more puppetruns will able to be pushed from Satellite 6 on clients. Indeed in Satellite 6.1.X puppetruns executed via Satellite are disabled.

For one of our biggest customer in Spain this is a big issue because now we are running on demand puppetruns via satellite6 using puppet kick method. Now we have 1 Satellite 6.0.8 central server (+1 DR), 8 capsules 6.0.8 and around 4000 clients.

The solution for this issue is the use of "Remote Execution" feature provided on Satellite 6.2 so we are planing to migrate our satellite 6.0.8 infra to satellite 6.2, but again we have faced another problem, in the first implementation of "Remote Execution" in Satellite 6.2.X only SSH will be used as provider and oir customer has completely forbidden to use ssh keys between servers (keep in mind that this is a bank).  So again we are blocked, we must wait to satellite 6.3 to be able to use Remote Execution with AMPQ or Salt Stack as providers (because SSH and Ansible are using SSH-Keys) so the questions for as are the following:

* Can you certify to us that AMPQ or Salt Stack Remote execution providers are not using SSH-keys ?

* Is any chance to implement AMPQ or Salt Stack Remote execution providers on Satellite 6.2.X in order to do not wait until Satellite 6.3 ? (Our satellite 6 infra upgrade is blocked because of this issue)


Many thanks in advence
Comment 3 Ivan Necas 2016-08-02 08:53:23 EDT
*** Bug 1362309 has been marked as a duplicate of this bug. ***
Comment 11 Ivan Necas 2017-04-13 06:05:05 EDT
Based on other priorities, work on this has been postponed during the last few months, but the engineering team plans to start looking into this again in next weeks time and we should have better estimates on when it's realistic to deliver based on that. I expect it would not be part of 6.3 GA, but should be possible to backport in 6.3.z stream, depending on when the 6.3 will be released. Anyway, this is quite rough estimation: we will know better after we get more into details, also taking into account some scalability improvements, that are related to this
Comment 12 Bryan Kearney 2017-05-10 08:55:10 EDT
As Ivan said, I would not expect to see this any earlier than a 6.3 zStream.
Comment 13 Bryan Kearney 2017-08-11 08:50:49 EDT
Reudcing from Urgent. PM, copied, is aware of the priority of this request.
Comment 14 Johan Bergström 2017-10-05 09:07:50 EDT
Also need this, ssh from capsules/satellite server towards hosts is prohibited from a network security policy point of view, need a "more secure" transport. AMPQ as in an already existing message queue would be preffered I guess.
Comment 15 Bryan Kearney 2018-01-18 14:50:29 EST
*** Bug 1393470 has been marked as a duplicate of this bug. ***
Comment 20 Martin Juhl 2018-03-13 06:08:41 EDT
+1 on this from a security POV

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