Lab 5.4 - how to solve the challenge step?

mark.kharitonov

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

[email protected]:~$ k get psp privileged
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME         PRIV   CAPS   SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
privileged   true   *      RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            *
[email protected]:~$ k describe clusterrole psp:privileged
Name:         psp:privileged
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                   Non-Resource URLs  Resource Names  Verbs
  ---------                   -----------------  --------------  -----
  podsecuritypolicies.policy  []                 [privileged]    [use]
[email protected]:~$ k describe clusterrolebinding any:psp:privileged
Name:         any:psp:privileged
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  psp:privileged
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:serviceaccounts
  Group  system:authenticated
[email protected]:~$ k auth can-i --as system:serviceaccounts:dev-ns:simple-sa use psp/privileged
Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
yes
[email protected]:~$ k auth can-i --as system:serviceaccounts:default:default use psp/privileged
Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
yes
[email protected]:~$ k auth can-i use psp/privileged
Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
yes
[email protected]:~$

Phase 2

[email protected]:~/5$ k -n dev-ns get psp
Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
no-priv      false          RunAsAny   MustRunAsNonRoot   RunAsAny   RunAsAny   false            *
privileged   true    *      RunAsAny   RunAsAny           RunAsAny   RunAsAny   false            *
[email protected]:~/5$ k -n dev-ns describe role psp:no-priv
Name:         psp:no-priv
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources                   Non-Resource URLs  Resource Names  Verbs
  ---------                   -----------------  --------------  -----
  podsecuritypolicies.policy  []                 [no-priv]       [use]
[email protected]:~/5$ k -n dev-ns describe rolebinding any:psp:no-priv
Name:         any:psp:no-priv
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  psp:no-priv
Subjects:
  Kind   Name                           Namespace
  ----   ----                           ---------
  Group  system:authenticated
  Group  system:serviceaccounts:dev-ns
[email protected]:~/5$ k -n dev-ns auth can-i --as system:serviceaccount:dev-ns:default use psp/no-priv
Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
yes
[email protected]:~/5$ k -n dev-ns auth can-i use psp/no-priv
Warning: resource 'podsecuritypolicies' is not namespace scoped in group 'policy'
yes
[email protected]:~/5$ k -n dev-ns get pod,rs,deploy
No resources found in dev-ns namespace.
[email protected]:~/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:

[email protected]:~/5$ k run --image=mariadb db-one --port=3306 --env="[email protected]" -n dev-ns
pod/db-one created
[email protected]:~/5$  k create -f db-two.yaml
deployment.apps/db-two created
[email protected]:~/5$ k -n dev-ns get pod,rs,deploy
NAME                         READY   STATUS              RESTARTS   AGE
pod/db-one                   0/1     ContainerCreating   0          14s
pod/db-two-cfb5c47db-llbq8   0/1     ContainerCreating   0          3s

NAME                               DESIRED   CURRENT   READY   AGE
replicaset.apps/db-two-cfb5c47db   1         1         0       3s

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/db-two   0/1     1            0           3s
[email protected]:~/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:

[email protected]:~/5$ k -n dev-ns get pod,rs,deploy
NAME                         READY   STATUS    RESTARTS   AGE
pod/db-one                   1/1     Running   0          2m30s
pod/db-two-cfb5c47db-llbq8   1/1     Running   0          2m19s

NAME                               DESIRED   CURRENT   READY   AGE
replicaset.apps/db-two-cfb5c47db   1         1         1       2m19s

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/db-two   1/1     1            1           2m19s
[email protected]:~/5$

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