Bug 1386336

Summary:	SSH configuration should support keys protected by passphrases
Product:	OpenShift Container Platform	Reporter:	Michael Epley <mepley>
Component:	RFE	Assignee:	Ben Parees <bparees>
Status:	CLOSED WONTFIX	QA Contact:	Xiaoli Tian <xtian>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.3.0	CC:	aos-bugs, jokerman, mepley, mmccomas
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-06-12 11:57:55 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michael Epley 2016-10-18 17:13:01 UTC

Description of problem:

I have customers that require all keys to be protected by passphrases by corporate policy. OCP in various places requires passphrases to be unprotected.

Version-Release number of selected component (if applicable):

As of OCP 3.3

How reproducible:

Perfectly. OCP does not support passphrases for ssh operations within its standard builder images and within its standard toolchain (such as the oc CLI). See https://docs.openshift.com/container-platform/latest/dev_guide/builds.html

Steps to Reproduce:
1. For example, access to a git source code repository protected by client-cert authentication requires a BuildConfig spec.source.sourceSecret containing a valid client auth key.
2. recreate the example described in https://blog.openshift.com/using-ssh-key-for-s2i-builds/ , but use a passphrase protected ssh key.
3. The build will fail.

Expected results:

Implementations should be provided to allow the use of passphrase protected keys throughout OCP. The passphrase should be maintained in a secret or other protected storage mechanism and otherwise by hidden/obfuscated from stdout/stderr, logs, and other potential places. The OCP toolchain (CLI, GUI, etc) should allow the population of the passphrase data (for example, into a secret).

Additional info:

Potential workarounds for some OCP features may be available, such as custom builder images that use ssh-agent to load ssh key passphrases from a well-known mounted secret. This is not ideal as it requires significant modification, needs to be maintained by the end-user, and is still not fully supported by the OCP toolchain(s).

Comment 1 Ben Parees 2016-12-05 15:05:45 UTC

Storing the passphrase along with the key itself seems insecure, it's hard to believe any customer who requires passphrases for their keys would be happy with a solution in which the passphrase was stored with the key.  It would mean anyone who can access the key, can also access the passphrase, which completely circumvents the purpose of having passphrases associated with keys.

Therefore i'm having trouble understanding the value of this feature, since i can't believe anyone with such security policies would actually adopt it as a solution.

Comment 2 Ben Parees 2017-01-16 15:22:52 UTC

@Michael, per my previous comment, we're not in favor of this RFE, pending a response from you I'm going to close it.

it is also possible to create a passphrase-less key from a key with a passphrase, so users could simply do that to create the key they store in the secret.

Comment 3 Michael Epley 2017-01-16 18:31:53 UTC

@Ben

Agreed; storing a passphrase and key in insecure but asaik there are limited ways to unlock a key autonomously without doing so. The chosen mechanism however can provide a certain amount of access control and/or obfuscation to prevent disclosure of these outside of well known contexts.

As I mentioned, I have customers that issue keys with passphrases (often for example, server keys or personal signing or encrypting keys). Use of the keys is required and by policy must be protected by a passphrase. Normally, the key owner (e.g. a system admins with restricted access in the case of a server cert) would enter the passphrase manually (e.g. when the system or application is restarted). In the context of the automated deployment or other mechanisms in OCP this is impractical and either an automated way to provide the passphrase or removal if the passphrase is required.

Use a passphrase can be automated with a certain amount of obfuscation (e.g. the git builder image example previously noted using ssh-agent and passphrase loaded into a secret) and my customers have validated/prototyped this approach. They agree it a preferred approach to simply removal of the passphrase (against corporate policy, which is very unlikely to be changed).

In terms or security both approaches appear roughly comparable: in the case of passphrase removal, any user with access to the OCP container can extract an unprotected private key; in the case of an obfuscated passphrase access any user with access to the OCP container can get the passphrase and protected key and convert the key to an unprotected one.

However, at least in the case of using obfuscated mechanisms around a passphrase protected key could potentially allow for improved security controls. For example, different users could inject the passphrase and key (potentially at different places in the build or deployment process) and handling/storage of unprotected passphrases in a developer/local workstation, scripts, or other places could be limited or avoided altogether.

Comment 5 Kirsten Newcomer 2019-06-12 11:57:55 UTC

With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers.  Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant.

This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. 

If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new 

Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new 

As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system.