Namespace does not have PSS level assigned

[uri-peled-unit]

Issue Summary

I have noticed that the Helm chart is missing the necessary annotations for PodSecurityPolicy enforcement.

Problem Description

The Helm chart is missing the following annotations in the pod template:

annotations:
  pod-security.kubernetes.io/enforce: "restricted"

This annotation is crucial for enforcing the PodSecurityPolicy "restricted" on the pods, and its absence may lead to security concerns.

Steps to Reproduce

1. Install the Helm chart with the specified version.
2. Observe the absence of the mentioned annotations in the deployed pods.

Expected Behavior

I expected the Helm chart to include the necessary annotations in the pod template out of the box, specifically:

annotations:
  pod-security.kubernetes.io/enforce: "restricted"

Proposed Solution

It would be beneficial if the Helm chart could be updated to include the missing annotations for proper PodSecurityPolicy enforcement.

Enforcing the pod-security.kubernetes.io/enforce: "restricted" annotation in Kubernetes is important for several reasons:

1. Security Compliance: Ensures compliance with security best practices and organizational policies.

2. Least Privilege: Follows the principle of least privilege, limiting pod permissions to minimize security risks.

3. Preventing Escalation: Mitigates the risk of privilege escalation within containers.

4. Defense in Depth: Adds an extra layer of defense to the Kubernetes cluster.

5. Risk Reduction: Reduces the risk of security vulnerabilities and exploits.

6. Organizational Alignment: Aligns workloads with organizational security policies.

7. Cluster Hardening: Contributes to the overall security hardening of the Kubernetes cluster.

8. Auditing and Monitoring: Facilitates auditing and monitoring of security configurations.

Thank you for your attention to this matter.

[linear]

OSS-1 Namespace does not have PSS level assigned

[ekampf]

Hey @uri-peled-unit ,
Thanks for the feedback!
You can add said annotations to the connector pods using .Values.podAnnotations (see

helm-charts/stable/connector/values.yaml

Line 32 in ad95bae

podAnnotations: {}

)

Will discuss with team on wether we want to include this annotation by default.
Aren't these annotations better applied on namespaces or cluster level?

[uri-peled-unit]

Thanks for your reply 🙏🏽 In my opinion, Annotations in Kubernetes, particularly for third-party deployments like Twingate, can be beneficial at the namespace level to maintain a level of abstraction and ensure security. This allows for a "black box" approach for customers, enhancing security while ensuring service excellence. For in-house product development, the flexibility to apply annotations per pod offers granular control tailored to specific needs. It's a balance between encapsulating third-party solutions and empowering internal teams with customization. Annotations in clusters level should be used for network policies or ingress and not for the restricted profile of PSS. *Uri Peled* Cloud Security Manager *M:* +972 52-5703-822 <https://twitter.com/unit_co_> <https://www.linkedin.com/company/unit-finance/> <https://www.unit.co/>

…

On Tue, 16 Jan 2024 at 19:54 Eran Kampf ***@***.***> wrote: Hey @uri-peled-unit <https://github.com/uri-peled-unit> , Thanks for the feedback! You can add said annotations to the connector pods using .Values.podAnnotations (see https://github.com/Twingate/helm-charts/blob/ad95baea05a0f2d7e9c2e5e3d7d64bcfd0d8453c/stable/connector/values.yaml#L32 ) Will discuss with team on wether we want to include this annotation by default. Aren't these annotations better applied on namespaces or cluster level? — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5GDAHUBSLXL5MPI5KQF2HTYO25ELAVCNFSM6AAAAABB2IZ4BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGIZTCNRQGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ekampf]

@uri-peled-unit I tried testing it and I'm not sure this annotation even works on the pod level? didnt work for me...
But when setting it on my namespace I did get a bunch of errors to connectors so we need to look into fixing those to make the container compatible with "restricted" mode

[uri-peled-unit]

Yep. This is why I raised this issue 🙏🏽 *Uri Peled* Cloud Security Manager *M:* +972 52-5703-822 <https://twitter.com/unit_co_> <https://www.linkedin.com/company/unit-finance/> <https://www.unit.co/>

…

On Tue, 16 Jan 2024 at 20:40 Eran Kampf ***@***.***> wrote: @uri-peled-unit <https://github.com/uri-peled-unit> I tried testing it and I'm not sure this annotation even works on the pod level? didnt work for me... But when setting it on my namespace I did get a bunch of errors to connectors so we need to look into fixing those to make the container compatible with "restricted" mode — Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A5GDAHU5ZOBBHZ3JTQU4VVDYO3CR5AVCNFSM6AAAAABB2IZ4BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGMYTGNJYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Yaronsohn]

Hey @uri-peled-unit,

The most common source of vulnerabilities within images are the libraries and executables that an image contains.
The more you have the more likely you will have to update the image often.
Moreover, the more executables in the image the more likely an attacker might be able to break the sandbox.

Our approach is to keep the image code footprint as small as possible to avoid the aforementioned.
This is a double edge sword, as it also limits what we can do.
Because the connector does need permission to access some of the resources in the container (which a normal user might not have the access) performing the fine tuning will require more libraries and executables to be included and that negates our lean image approach.

Because the Kubernetes runtime enforces a sandbox environment anyway, a solution where you have a root that can not do anything is more secure than a normal user that has all the tools in his disposal.

I'll be happy to discuss this further.

[ekampf]

@uri-peled-unit we're testing a fix to our Connector docker file to run nonroot. Expecting to have this feature available in the coming connector release.
We're still using distroless, keeping our footprint minimal, but found a way to make it run not on the root user to allow auditing\compliance tools to ✅ it ;)

Note that this is not a helm-charts issue and once new connector images are released there's no changes required on this repo, but I'm keeping this issue open for now and will close it when we release.