Welcome to the Linux Foundation Forum!

Lab 5.4 - how to solve the challenge step?

To recap - the challenge is to use what you have learned about service accounts and RBAC roles to limit a psp to the dev-ns namespace.

My idea to solve the challenge is:
1. Create a PSP to allow everything and let everyone use it across all the namespaces.
2. A second PSP (the target) will be only allowed by all the accounts in the dev-ns namespace.

Phase 1

  1. student@master:~$ k get psp privileged
  2. Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
  3. NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
  4. privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *
  5. student@master:~$ k describe clusterrole psp:privileged
  6. Name: psp:privileged
  7. Labels: <none>
  8. Annotations: <none>
  9. PolicyRule:
  10. Resources Non-Resource URLs Resource Names Verbs
  11. --------- ----------------- -------------- -----
  12. podsecuritypolicies.policy [] [privileged] [use]
  13. student@master:~$ k describe clusterrolebinding any:psp:privileged
  14. Name: any:psp:privileged
  15. Labels: <none>
  16. Annotations: <none>
  17. Role:
  18. Kind: ClusterRole
  19. Name: psp:privileged
  20. Subjects:
  21. Kind Name Namespace
  22. ---- ---- ---------
  23. Group system:serviceaccounts
  24. Group system:authenticated
  25. student@master:~$ k auth can-i --as system:serviceaccounts:dev-ns:simple-sa use psp/privileged
  26. Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
  27. yes
  28. student@master:~$ k auth can-i --as system:serviceaccounts:default:default use psp/privileged
  29. Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
  30. yes
  31. student@master:~$ k auth can-i use psp/privileged
  32. Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
  33. yes
  34. student@master:~$

Phase 2

  1. student@master:~/5$ k -n dev-ns get psp
  2. Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
  3. NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
  4. no-priv false RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false *
  5. privileged true * RunAsAny RunAsAny RunAsAny RunAsAny false *
  6. student@master:~/5$ k -n dev-ns describe role psp:no-priv
  7. Name: psp:no-priv
  8. Labels: <none>
  9. Annotations: <none>
  10. PolicyRule:
  11. Resources Non-Resource URLs Resource Names Verbs
  12. --------- ----------------- -------------- -----
  13. podsecuritypolicies.policy [] [no-priv] [use]
  14. student@master:~/5$ k -n dev-ns describe rolebinding any:psp:no-priv
  15. Name: any:psp:no-priv
  16. Labels: <none>
  17. Annotations: <none>
  18. Role:
  19. Kind: Role
  20. Name: psp:no-priv
  21. Subjects:
  22. Kind Name Namespace
  23. ---- ---- ---------
  24. Group system:authenticated
  25. Group system:serviceaccounts:dev-ns
  26. student@master:~/5$ k -n dev-ns auth can-i --as system:serviceaccount:dev-ns:default use psp/no-priv
  27. Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
  28. yes
  29. student@master:~/5$ k -n dev-ns auth can-i use psp/no-priv
  30. Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
  31. yes
  32. student@master:~/5$ k -n dev-ns get pod,rs,deploy
  33. No resources found in dev-ns namespace.
  34. student@master:~/5$

Now I am going to create the pod db-one and deployment db-two in the dev-ns namespace. The respective pods require to run as root, which is forbidden by the no-priv policy - we already saw it earlier in the lab. My expectation is that the policy would prevent the pods from starting:

  1. student@master:~/5$ k run --image=mariadb db-one --port=3306 --env="MYSQL_ROOT_PASSWORD=LFtr@in" -n dev-ns
  2. pod/db-one created
  3. student@master:~/5$ k create -f db-two.yaml
  4. deployment.apps/db-two created
  5. student@master:~/5$ k -n dev-ns get pod,rs,deploy
  6. NAME READY STATUS RESTARTS AGE
  7. pod/db-one 0/1 ContainerCreating 0 14s
  8. pod/db-two-cfb5c47db-llbq8 0/1 ContainerCreating 0 3s
  9.  
  10. NAME DESIRED CURRENT READY AGE
  11. replicaset.apps/db-two-cfb5c47db 1 1 0 3s
  12.  
  13. NAME READY UP-TO-DATE AVAILABLE AGE
  14. deployment.apps/db-two 0/1 1 0 3s
  15. student@master:~/5$

And already we can see that my idea does not work. If the no-priv policy actually worked in the dev-ns namespace, then the replica controller would not have been able to create the pod, but it did. And right now the situation is that all is running, despite my expectations:

  1. student@master:~/5$ k -n dev-ns get pod,rs,deploy
  2. NAME READY STATUS RESTARTS AGE
  3. pod/db-one 1/1 Running 0 2m30s
  4. pod/db-two-cfb5c47db-llbq8 1/1 Running 0 2m19s
  5.  
  6. NAME DESIRED CURRENT READY AGE
  7. replicaset.apps/db-two-cfb5c47db 1 1 1 2m19s
  8.  
  9. NAME READY UP-TO-DATE AVAILABLE AGE
  10. deployment.apps/db-two 1/1 1 1 2m19s
  11. student@master:~/5$

So my scheme does not work and I have no idea how to solve the challenge. Please, help. Thank you.

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Welcome!

It looks like you're new here. Sign in or register to get started.
Sign In

Categories

Upcoming Training