Thank you for your explanation. I have one practical question. From my understanding, in the pod security admission(PSA), there is no customization feature. We can only select one of the security levels (privileged, baseline or restricted) Now, there is a pod which uses capability CAP_NET_ADMIN only. But, the ‘baseline’ level of PSA doesn’t have CAP_NET_ADMIN. As a result, should this pod be created with ‘privileged’ level, even though the pod needs only one capability? (In case I don't use webhook or other tool for it)
You can Enforce Pod Security Standards by Configuring the Built-in Admission Controller, i.e. by using Exemptions Check this link kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/ Or you can achieve such using alternatives such as Kubewarden, Kyverno, OPA Gatekeeper etc
Hey thanks for detailed explanation, I have couple questions: 1. I see that multiple pod-security lables can be applied to a namespace. What will happen if I apply labels with MODE: 'warn' and 'enforce' for PROFILE: 'restricted'. Does it create new baseline security context pod? What action will be enforced at the end or will there be some conflict? 2. Is kube-system namespace expemted from this change?
Thanks for feedback and keep learning 1. Yes You can apply multiple lablels to namespace. If Your profile is Restricted, means its hardened, on top of it you are applying warn and enforce. Will apply based on allowed boundary and enforce will take precedence 2. I think kube-system is excempted. I hope iam not wrong and appreciate if you know more pls share here.
Hi @Learn With GVR, I want to restrict users from running cp/scp/rsync/sftp commands inside the containers running in the kubernetes. I understand that we should only have needed packages available inside the application images. But in our system, lots of applications are already running and we can't control that as of now. I was wondering if we have a way to achieve the same by using PodSecurityPolicy or PodSecurity admission controller. Let me know your thoughts around the same.
In my opinion... for your requirement i.e., preventive control. hence you can't achieve with PSP or PSA limitation options are... use distroless base images, or use apparmor or seccomp or sandboxin etc container hardening tools will help to achieve. choose the tool which suits your use case. hope this helps and thanks for asking
bro ye video to awesome h no doubt i jst wnna ask u if i want to store my secrets so which one could be the best option aws secrets manager or hashicorp vault accrdng to price n all things
Yes psa applicable to windows pids aswell but no effect. many of the pod securityContext fields have no effect on Windows, such as runAsUser, runAsGroup, seLinuxOptions, and more. If you specify .spec.os.name to windows most of the restricted settings won't work. So you need to tweak based on limitation.
Very detailed explanation about PodSecurity admission controller. This session is very helpful, Ramana.
Glad it was helpful!. Thank you
Thank you so much for detailed explanation. Its really helpful
Thank you for the feedback
Hey, thanks for the session and CKS playlist. Can you also share a video about your kube setup?
Thank you bro, keep learning
Hi Ramanan, thank you! Really helpful explanation.
Thank you for the feedback, Keep learning
Great explanation. Thank you!!
Thank you
Tnx very good
Thank you
thanks, Very detailed explanation
You are welcome! Cheers and keep learning
very help to understand the topic
Thank you Suraj
Thanks Ramana, a very good session, Just one question, if we enable PSA at cluster level, will it add the labels to the namespaces automatically ?
No, pod security admission controller doesn't add any labels to namespace. cluster admin has to take care of this
amazing explanation
Thank you
Really nice, Thanks for the help!!!
Thank you Orianna. Keep learning
Thank you for your explanation. I have one practical question.
From my understanding, in the pod security admission(PSA), there is no customization feature. We can only select one of the security levels (privileged, baseline or restricted)
Now, there is a pod which uses capability CAP_NET_ADMIN only. But, the ‘baseline’ level of PSA doesn’t have CAP_NET_ADMIN. As a result, should this pod be created with ‘privileged’ level, even though the pod needs only one capability? (In case I don't use webhook or other tool for it)
You can Enforce Pod Security Standards by Configuring the Built-in Admission Controller, i.e. by using Exemptions
Check this link
kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/
Or you can achieve such using alternatives such as Kubewarden,
Kyverno,
OPA Gatekeeper etc
Hey thanks for detailed explanation, I have couple questions:
1. I see that multiple pod-security lables can be applied to a namespace. What will happen if I apply labels with MODE: 'warn' and 'enforce' for PROFILE: 'restricted'. Does it create new baseline security context pod?
What action will be enforced at the end or will there be some conflict?
2. Is kube-system namespace expemted from this change?
Thanks for feedback and keep learning
1. Yes You can apply multiple lablels to namespace. If Your profile is Restricted, means its hardened, on top of it you are applying warn and enforce. Will apply based on allowed boundary and enforce will take precedence
2. I think kube-system is excempted. I hope iam not wrong and appreciate if you know more pls share here.
Really helpful!! Thanks :)
You're welcome! Thanks for watching. Pls share and subscribe
IS THIS THE COMPLETE TRAINING PLAYLIST ON KUBERNETES SECURITY ?
yes pls check my playlists in the channel
Hi @Learn With GVR,
I want to restrict users from running cp/scp/rsync/sftp commands inside the containers running in the kubernetes. I understand that we should only have needed packages available inside the application images. But in our system, lots of applications are already running and we can't control that as of now. I was wondering if we have a way to achieve the same by using PodSecurityPolicy or PodSecurity admission controller. Let me know your thoughts around the same.
In my opinion... for your requirement i.e., preventive control. hence you can't achieve with PSP or PSA limitation
options are... use distroless base images, or use apparmor or seccomp or sandboxin etc container hardening tools will help to achieve. choose the tool which suits your use case.
hope this helps and thanks for asking
Thanks for this
Thank you
bro ye video to awesome h no doubt i jst wnna ask u if i want to store my secrets so which one could be the best option aws secrets manager or hashicorp vault accrdng to price n all things
It depends on use case
Very nice
Thank you
Can we have custom Pod Security Standards?
No default PSS cannot be modified , but there are alternatives like OPA gatekeeper or Kyverno or Kubewarden.
@@learnwithgvr Got it, appreciate your quick response.
Your channel is very helpful to learn advanced k8s concepts. Thank you for your education 🙂
🙏
Hi Ramanan,Can you please share those yaml files github link which you have shown in this videos?
Please refer the video description for YAML files github repo
what about windows pods
? :)
Yes psa applicable to windows pids aswell but no effect. many of the pod securityContext fields have no effect on Windows, such as runAsUser, runAsGroup, seLinuxOptions, and more.
If you specify .spec.os.name to windows most of the restricted settings won't work. So you need to tweak based on limitation.
Thank you so much for detailed explanation. Its really helpful.
My pleasure, keep learning