Note: $ROLE_PROJECT is the project containing the role that I want to
assign to the service account in $SERVICEACCOUNT_PROJECT.
Here's the YAML I used to create the policybinding:
apiVersion: v1
kind: PolicyBinding
metadata:
name: $ROLE_PROJECT:default
policyRef:
name: default
namespace: $ROLE_PROJECT
roleBindings:
- name: testing
roleBinding:
metadata:
name: testing
namespace: $ROLE_PROJECT
roleRef:
name: testing
namespace: $ROLE_PROJECT
subjects:
- kind: ServiceAccount
name: system:serviceaccount:$SERVICEACCOUNT_PROJECT:testing
userNames: null
Terminal session after creating the above:
$ oc policy add-role-to-user --role-namespace=$ROLE_PROJECT testing -z
testing
The RoleBinding "testing" is invalid.
* metadata.resourceVersion: Invalid value: "": must be specified for an
update
* metadata.resourceVersion: Invalid value: "": must be specified for an
update
$ oc project $SERVICEACCOUNT_PROJECT
Now using project "$SERVICEACCOUNT_PROJECT" on server "
https://example.com:8443";.
$ oc policy add-role-to-user --role-namespace=$ROLE_PROJECT testing -z
testing
Error from server: policybinding "$ROLE_PROJECT:default" not found
$ oc get policybinding -n $ROLE_PROJECT
NAME ROLE BINDINGS
LAST MODIFIED
:default admin, system:deployers, system:image-builders,
system:image-pullers 2016-06-22 01:59:45 -0500 CDT
$ROLE_PROJECT:default testing
Looks like there's something I don't understand about policies, policy
bindings, roles, service accounts, and how they all fit together.
On Wed, Jul 6, 2016 at 8:12 PM, Jordan Liggitt <[email protected]> wrote:
> Can you show the output of this command while your project is in that
> state?
>
> oc get policybindings -o yaml
>
> On Wed, Jul 6, 2016 at 5:51 PM, Alex Wauck <[email protected]> wrote:
>
>> I did create a "role-namespace:default" policy binding object. After
>> creating it, the project disappeared from the list (but it was still
>> accessible via direct links). After deleting it, the project reappeared.
>>
>> On Wed, Jul 6, 2016 at 4:28 PM, Jordan Liggitt <[email protected]>
>> wrote:
>>
>>> A policy binding object name consists of the namespace where the roles
>>> are defined (or the empty string for cluster-level roles) and the name of
>>> the policy object (which is currently pinned to "default").
>>>
>>> When you created (or overwrote) the ":default" policy binding object, it
>>> removed bindings to cluster-level roles, which likely removed your user's
>>> access to the project.
>>>
>>> To bind to roles defined in "role-namespace", create a policy binding
>>> object named "role-namespace:default".
>>>
>>>
>>> On Wed, Jul 6, 2016 at 5:17 PM, Alex Wauck <[email protected]>
>>> wrote:
>>>
>>>> I want to bind a service account defined in one project to a role
>>>> defined in another. Apparently, I need to create a :default policybinding
>>>> for the project containing the role. I tried doing this, but then the
>>>> project stopped showing up in the list of projects in the Web UI. Why do I
>>>> need this policybinding, and what does it need to contain in order to not
>>>> break the Web UI?
>>>>
>>>> I am running OpenShift Origin 1.2.0.
>>>>
>>>> --
>>>>
>>>> Alex Wauck // DevOps Engineer
>>>>
>>>> *E X O S I T E*
>>>> *www.exosite.com <http://www.exosite.com/>*
>>>>
>>>> Making Machines More Human.
>>>>
>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> [email protected]
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>>>
>>>>
>>>
>>
>>
>> --
>>
>> Alex Wauck // DevOps Engineer
>>
>> *E X O S I T E*
>> *www.exosite.com <http://www.exosite.com/>*
>>
>> Making Machines More Human.
>>
>>
>
--
Alex Wauck // DevOps Engineer
*E X O S I T E*
*www.exosite.com <http://www.exosite.com/>*
Making Machines More Human.
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
