cancel
Showing results for 
Search instead for 
Did you mean: 
Jcalvod
Flight Engineer
Flight Engineer
  • 729 Views

do280 v4.12 - compreview-review - Why lab-grade evalue this points as an error ?

Jump to solution

1) If the statement present at the end is:

"As the do280-support user, you must create the do280-attendees group with the do280-attendee user, and assign the edit cluster role to the do280-attendees group."

Why appear to be invalid to execute :
oc adm policy add-cluster-role-to-group edit do280-attendees
? . If you simply add the edit role in the project and not follow letter by letter the statement the result is ok but i do not understand why RedHat write that statement and not correct "cluster role" and change it to local role.

2) In the same exercise another statement is:
"Each workshop project must have this additional default configuration:

  • A local binding for the presenter user to the admin cluster role with the workshop name

  • The workshop=project_name label to help to identify the workshop workload

  • Must accept traffic only from within the same workshop or from the ingress controller."

In this point 2 doubts:

First:

If in the statement is not especified that you have to use the project label:  workshop=${PROJECT_NAME} in the Network Policy, why if you use the label: project=${PROJECT_NAME} the result is INVALID in the evalutation if really do the same ?

Second:

If in the statement explicitly say: Must accept traffic only from within the same workshop or from the ingress controller. and in the doumentation you can find an example to use the label

network.openshift.io/policy-group: ingress

to allow connections from the OpenShift Container Platform Ingress Controller... why is mandatory to use the another one that appear in the documentation to allow traffic from router:

policy-group.network.openshift.io/ingress: ""


This kind of issues really decrease your score without represent that you haven't knowledges...
If anybody can explain me another point of view to understand why i am not uderstanding the statements i appreciate it very much.

Thanks!

 

Labels (3)
1 Solution

Accepted Solutions
cipid2001_linux
Mission Specialist
Mission Specialist
  • 620 Views

1) "edit" is a cluster role => #oc get clusterrole.rbac/edit. You will not find edit at the role.rbac. But this cluster role can be bind at cluster level binding or project level binding.  

About the bindings - even if the edit is a cluster role, it can be bind at cluster level or project level => # oc get clusterrolebindings.rbac (for cluster role bindings) or #oc get rolebindings.rbac (for project role bindings).

That's why there are two commands and you need to make a difference between them and where it is needed the role to be added:

#oc adm policy add-cluster-role-to-group edit test  => it is adding at cluster binding in clusterrolebindings.rbac

#oc adm policy add-role-to-group edit test  => it is adding at project binding in rolebindings.rbac

I think RH script is evaluating if the binding is present in rolebindings.rbac/edit 

2) workshop=${PROJECT_NAME} and project=${PROJECT_NAME} are 2 different labels. A label is based on key:value. Even if the value is the same, the keys are different.

Use the labels provided in the exercises and don't try to invent labels, even if with other labels will work. When you apply a network policy you should check the already present labels in your deployments.

3) About ingress : both statements are correct, but policy-group.network.openshift.io/ingress: "" is the new form and this will be used in the future.

cipid2001_linux_0-1716741364619.png

 

 

 

 

View solution in original post

1 Reply
cipid2001_linux
Mission Specialist
Mission Specialist
  • 621 Views

1) "edit" is a cluster role => #oc get clusterrole.rbac/edit. You will not find edit at the role.rbac. But this cluster role can be bind at cluster level binding or project level binding.  

About the bindings - even if the edit is a cluster role, it can be bind at cluster level or project level => # oc get clusterrolebindings.rbac (for cluster role bindings) or #oc get rolebindings.rbac (for project role bindings).

That's why there are two commands and you need to make a difference between them and where it is needed the role to be added:

#oc adm policy add-cluster-role-to-group edit test  => it is adding at cluster binding in clusterrolebindings.rbac

#oc adm policy add-role-to-group edit test  => it is adding at project binding in rolebindings.rbac

I think RH script is evaluating if the binding is present in rolebindings.rbac/edit 

2) workshop=${PROJECT_NAME} and project=${PROJECT_NAME} are 2 different labels. A label is based on key:value. Even if the value is the same, the keys are different.

Use the labels provided in the exercises and don't try to invent labels, even if with other labels will work. When you apply a network policy you should check the already present labels in your deployments.

3) About ingress : both statements are correct, but policy-group.network.openshift.io/ingress: "" is the new form and this will be used in the future.

cipid2001_linux_0-1716741364619.png

 

 

 

 

Join the discussion
You must log in to join this conversation.