Bug 1318567 - Cannot rsh to pod that mounts hostmount volume(s)
Summary: Cannot rsh to pod that mounts hostmount volume(s)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: ---
Assignee: Fabiano Franz
QA Contact: Wei Sun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-17 09:18 UTC by Josef Karasek
Modified: 2016-03-18 12:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-18 12:35:04 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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