specify value for "spec.subjects.properties.version" doesn't work as expected in ServiceRoleBinding #6012
Assignees
Labels
Comments
|
Hi Morven, Thanks for reporting the issue. cc @liminw |
|
@yangminzhu Thanks for quick reply. The product will be not accessed, get My problem is that While this one does not:(I'd like to only see “red” ratings in “Book Reviews” section) |
|
No error message in mixer log: |
|
So the RBAC seems enabled correctly, could you run the following command to get the authorization template: It might be the version label incorrectly configured in authorization template or pods. |
|
Seems version label is correct: After I specify |
|
@yangminzhu The conditions defined in |
|
Yes, the subjects in ServiceRoleBinding are evaluated with OR relationship. So I suggest to turn on the Mixer debug logging to get more information. You could edit the istio-policy deployment to add this It seems everything is configured correctly, I also tried your use case on Istio-0.8 this afternoon and it's working as expected for me. |
I think this is a doc issue, you can checkout it here: I have defined ServiceAccount An the end of this section, it mentions:
|
|
Sorry if my last reply mislead you, the subjects is an array, I actually mean each subject in the array are OR, for fields inside a subject, the relationship is AND. The semantic is that it grants access to {userA and version=v3} OR {userB and version=v2}. The expect behavior in your ServiceRoleBinding should be that only bookinfo-reviews with version=v3 is allowed to access. Could you also run |
|
All BTW, have opened |
|
@yangminzhu istio-policy logs with debug flag: |
|
The logs seems doesn't include the information when the request is happening, could you try again? If you look at your previous mixer logs, it contains a lot of adapters logs which is missing in your new log, also I'm expecting to see the attributes for each request to be logged which is also missing. Last, I feel this round trip is not very efficient, how about let's have a short video conference to discuss about it? |
|
What about this one? For the whole logs file is two large, I have cut the head part. It's OK for me to have a conference, but my time zone is different from your. Anyway, please check the logs firstly. |
|
@yangminzhu you will have the issue when you run to the last step of https://istio.io/docs/tasks/security/role-based-access-control/#enabling-istio-rbac after configure the |
|
@morvencao I looked at the istio-policy.log you provided. It seems that the value for source.labels attribute is "unknown". If this is true, there may be a bug in Pilot/proxy for distributing the labels. I will see if I can reproduce it in my environment. |
|
@morvencao @gyliu513 In my previous test, I only included the Thanks for reporting this and sorry for the trouble. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
env:
Reproduce steps
istio-0.8.0with mTLS:In the last step, I would like to only see “red” ratings in “Book Reviews” section, so I specify that only “reviews” service at version “v3” can access “ratings” service following the doc by update
bind-ratingsServiceRoleBinding with:Point the browser to the Bookinfo productpage (http://$GATEWAY_URL/productpage). Still I can should see the “black” and “red” ratings in “Book Reviews” section.
The results show that both review v2 and v3 can access ratings service.
Expected: Only “red” ratings in “Book Reviews” section.
/cc @gyliu513
The text was updated successfully, but these errors were encountered: