Kubernetes apps should be secure in the sense that the pods, cannot take control of the host TrueNAS. However, an external attacker could take control of the pod and from there, access the specific datasets and try to access your network. You would be dependent on the security of the specific apps. It would be similar to CORE jails and plugins.
To avoid this risk, we'd recommend a VPN to the Apps rather than allowing general Internet access...
TrueCharts apps can be made reachable via wireguard VPN.
It would be good to hear what security experts would say about this summary... please comment.
We take security very serieusly, hereby some notes for both you and
@Kraken
Secure Containers
In an ideal case, Apps do not run as root and do not have write access to the root filesystem.
This is our default for all Apps and we only deviate from that, if certain containers cannot be run with those security limitations.
However: there are
A LOT (the majority) of bad containers out there, sadly enough. Someday we might aim to make more ourselves, but that is a multi-year roadmap pointer.
Note:
Most official Apps and all (!) "big blue button" created Apps, do not apply many of the build in Kubernetes security precautions. Hence we, generally, consider those to be "less secure".
Secure Extenal Connectivity
There are 2 generally used connectivity options:
1. Using Ingress
2. Exposing the ports on the host (either LoadBalancer or NodePort)
Of those 2, Ingress is, generally the most secure.
VPN
An excilent idea by
@morganL , but we have to note we have not tested access to applications web-GUI's from the outside using VPN yet. It should, however, "just work".
Internal Network/subnet Security
We, by default, deploy our Apps without so called "networkPolicies", that means that all Apps can communicate with eachother. We also do not support the use of SSL within the internal kubernetes network. This is a bug security issue.
In the future we aim to add "networkPolicies" that allow the user to specify that certain Apps cannot communicate with other apps internally. This feature is on the "todo" list for release of SCALE or shortly after.
It is, however, crucial for secure production deployments, so we take that very serieusly.
Updates
Updates are CRUCIAL for a secure system, we generally update all Containers every week on Tuesdays.
To ensure everyone runs precisely(!) the same container version, we also digest-pin all container tags, which has the added benefids of being able to enforce updating if a new version on the same tag is pushed to docker.
Escaping the sandbox
If Apps you deploy use all kubernetes security hardening and you employ our Traefik Ingress provisioner (which is also slightly pre-hardened), the chances of sandbox escape from one container to the host are minimal. However: each layer of the security union that is removed, obviously, increases that chance.
Security Documentation
The above all sounds nice and well, but we are aware it's super hard for the average user to actually check which security settings are enabled (or disabled) with which Apps. We're not going to say "trust us", we are actually planning to give security gradings to each App, to allow users to decide for themselves if they trust a certain App.
Hope this gives some insight on the security tought proces (and we might actually copy-pasta this to the wiki as well, later).
K.S.
