Bug 1318567

Summary:	Cannot rsh to pod that mounts hostmount volume(s)
Product:	OpenShift Container Platform	Reporter:	Josef Karasek <jkarasek>
Component:	oc	Assignee:	Fabiano Franz <ffranz>
Status:	CLOSED NOTABUG	QA Contact:	Wei Sun <wsun>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.1.0	CC:	aos-bugs, jforrest, jkarasek, jokerman, mmccomas, pweil
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-18 12:35:04 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 Josef Karasek 2016-03-17 09:18:42 UTC

Description of problem:
After trying to connect to remote container, following error msg is shown. The oc command runs on laptop and OSE3 runs on remote server. Note that this behavior is not observed when running oc on the server, where the pod is deployed.

$ oc rsh archiva-1-br6as
Error from server: pods "archiva-1-br6as" is forbidden: unable to validate against any security context constraint: [provider restricted: .spec.containers[0].securityContext.VolumeMounts: invalid value 'archiva-data', Details: Host Volumes are not allowed to be used provider restricted: .spec.containers[0].securityContext.VolumeMounts: invalid value 'archiva-repositories', Details: Host Volumes are not allowed to be used]

Even though the pod is associated with it's own service account and the SA is registered with hostmount SCC.

Version-Release number of selected component (if applicable):
oc v3.1.1.6-21-gcd70c35
kubernetes v1.1.0-origin-1107-g4c8e6f4

How reproducible:
Bind a pod to hostmount volume and run oc rsh from remote PC.


Steps to Reproduce:
1.
2.
3.

Actual results:
Error msg and exit code 1

Expected results:
Remote connection to the container

Additional info:

Comment 1 Paul Weil 2016-03-17 15:20:22 UTC

It looks to me like the SA was granted access to an SCC that allowed host mounts but the user trying to exec into the pod does not have the same level of access as the SA. Exec is limited by ensuring the user trying to access pod X has the privileges necessary to create pod X.

I would guess oc on the server was executed as someone with elevated privileges?

You should be able to grant the correct SCC to the user and then they would be able to exec into the pod.  You can find the SCC used by running 'oc get pod <name> -o json | grep scc'.  Then you can run 'oadm policy add-scc-to-user'.  Be aware that the user would then be able to create pods with those elevated privileges.

Comment 2 Josef Karasek 2016-03-18 06:36:10 UTC

@Paul: Yes, that was the case. I used a user with restricted privileges to connect to a pod from hostmount scc. You can close this issue.

Thanks all for your help and time, I'll be more careful in the future.