Bug 1278180 - The oc client inside a container does not automatically use the service account secret in the container
The oc client inside a container does not automatically use the service accou...
Status: CLOSED CURRENTRELEASE
Product: OpenShift Origin
Classification: Red Hat
Component: Command Line Interface (Show other bugs)
3.x
All All
urgent Severity high
: ---
: ---
Assigned To: Clayton Coleman
Wei Sun
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-04 15:59 EST by Cesar Wong
Modified: 2015-11-23 16:17 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-23 16:17:18 EST
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)

  None (edit)
Description Cesar Wong 2015-11-04 15:59:24 EST
Description of problem:
When trying to use oc from within a container, it is expected that it would  use the service account associated with the pod. However, it currently requires that you specify --certificate-authority, --token, --server, and --namespace for it to properly work. 

Version-Release number of selected component (if applicable):
OpenShift Origin v3.1

How reproducible:
always

Steps to Reproduce:
1. Create a pod that includes the oc client (using a service account that can list pods)
2. Try to get pods 'oc get pods'

Actual results:
The command fails with an error message about no cluster defined

Expected results:
The command works

Additional info:
Comment 1 Cesar Wong 2015-11-04 16:01:50 EST
Additional clarification
for step 2 above:
- Exec into the container with 'oc rsh [podname]', then try to use the 'oc' command
Comment 2 Fabiano Franz 2015-11-05 11:15:35 EST
PR: https://github.com/openshift/origin/pull/5722
Comment 3 Clayton Coleman 2015-11-05 12:55:04 EST
https://github.com/openshift/origin/pull/5722
Comment 4 Xingxing Xia 2015-11-10 04:06:43 EST
Verification fails against version:
openshift/oc v1.0.8-4-gabfc3c4
kubernetes v1.1.0-origin-1107-g4c8e6f4

Verification steps:
1. oc login, create project
2. create new app
1> $ oc new-app -f origin/examples/sample-app/application-template-stibuild.json
2> $ oc get pod
NAME                        READY     STATUS             RESTARTS   AGE
database-1-rs0w0            1/1       Running            0          3h
3. Copy binary file "oc" to pod:
1> Create a directory in the pod container for "oc rsync"
$ oc exec database-1-rs0w0 -- mkdir /tmp/xxia
2> Do the copy. (Binary file "oc" is under "localdir")
$ oc rsync localdir/ database-1-rs0w0:/tmp/xxia
4. $ oc rsh database-1-rs0w0
bash-4.2$ /tmp/xxia/oc get pods
Unable to connect to the server: dial tcp 172.30.0.1:443: i/o timeout

Actual results:
4. Outputs error:
Unable to connect to the server: dial tcp 172.30.0.1:443: i/o timeout

Expected results:
4. The command works

Additional info
The above steps reproduce the bug if using old version oc such as v1.0.6.

Are the above steps right to verify the bug?
Comment 5 Jordan Liggitt 2015-11-10 09:54:17 EST
> The above steps reproduce the bug if using old version oc such as v1.0.6.

The bug was fixed in oc, so you need the latest version of oc. Are you saying it is only reproduceable in oc 1.0.6, or also in 1.0.8?
Comment 6 Cesar Wong 2015-11-10 13:30:45 EST
This is working for me on the latest master. A couple of things to remember:

1 - The service account that you are running the pod as must have permission to do the command that you invoke.  This can be accomplished with a command like:
$ oc policy add-role-to-user edit --serviceaccount=default

2 - Inside the pod, you must have the POD_NAMESPACE environment variable set to the current namespace. You can do this by either adding it to the deployment config or just set it before you invoke oc inside the pod:
$ export POD_NAMESPACE=myproject
$ oc get pods
Comment 7 Xingxing Xia 2015-11-10 21:43:25 EST
(In reply to Jordan Liggitt from comment #5)
> > The above steps reproduce the bug if using old version oc such as v1.0.6.
> 
> The bug was fixed in oc, so you need the latest version of oc. Are you
> saying it is only reproduceable in oc 1.0.6, or also in 1.0.8?

I mean that only 1.0.6 reproduces it. 1.0.8 does not reproduce it but has the issue as I described in the verification actual result. After testing according to your comment #6, that issue does not exist either.
Comment 8 Xingxing Xia 2015-11-10 21:48:10 EST
Verify again with the steps as in comment #4, and add the two points as in comment #6, the bug is fixed, the service account can run "oc get pods" successfully.

Move it to VERIFIED.

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