I’m considering using microk8s for something-close-to-production use. I understand about the issues surrounding whether a single-node kubernetes cluster could ever be considered ‘production’ quality. I’m not looking for reliability, monitorability or any of the other ‘production’ traits - just security. I want to know if I put a microk8s installation on a server that’s connected to the internet - is there anything inherently insecure about this?
Reasoning behind this: I just want a nice interface for orchestrating docker containers on a single server with external access, I’m familiar with kubernetes already as I run a cluster that’s actually for real production, and microk8s is a nice way of installing a single-node kubernetes cluster.
Every pod has its own routable IP address. Kubernetes takes care of routing all requests internally between hosts to the appropriate pod. External access to Kubernetes pods can be provided through a service, load balancer, or ingress controller, which Kubernetes routes to the appropriate pod.
Hence security of Kubernetes in Prod or Dev environment depends on your Cloud/DataCenter security.
If these components themselves are vulnerable then there’s no real way to guarantee the security of any components built on top of this base.
Thanks for the response! I understand the inherent security / risks of pods & ingresses, etc within a kubernetes environment and the details of securing an ubuntu server within a cloud / datacentre install.
What I’m asking is about the way that microk8s sets up the kubernetes control plane - is there anything I should be aware of with a microk8s installation as opposed to any other kubernetes installation: for example - does microk8s set up encrypted communications for the control plane? Does it set up a password for the control plane user? Is there anything unique to a microk8s installation which might pose a security risk? etc, etc.
We consider MicroK8s to be production ready. We have taken several steps towards secure deployments in the past couple of releases. Please, have a look at [1] to see what ports are opened and what authorization and authentication strategies we enable by default.
Very briefly, MicroK8s creates a CA and random tokens as soon as it gets installed. You can add tokens and assign them to users by editing /var/snap/microk8s/current/credentials/known_tokens.csv. To enable RBAC you do a microk8s.enable rbac. I would expect you review [1] and use a firewall so as not to expose all k8s ports to the world (even though most services bind to the localhost interface). You can review all service arguments at /var/snap/microk8s/current/args/, any feedback is welcomed.
One important security feature is that all MicroK8s deployments are upgraded with upstream patches within hours from their release [2].
It depends on your production application requirements. I manage an inventory of microk8s systems for industrial aerospace equipment. They are “production ready”. The one thing that isn’t explicitly related to microk8s but nonetheless is a critical failure for production systems is the Snapcraft package manager performs unattended upgrades on all snaps by default. In the case of microk8s, this will restart the service, causing an unexpected outage. This is Very Bad in cases where the software is controlling safety critical equipment.
The convenient time for updates in my application is when a human operator makes the decision to upgrade. Otherwise there are real world hazards that could be caused by the upgrade. For example, an application that moves through states to control high pressure gas plumbing.
It sounds like the Snapcraft package manager is not right for this environment. Looking at building from source.
I did a snap download using an offline package and it still auto updated which affects us as we are 1.15 and our configuration is not compatible with 1.17
@Konstantinos_Tsakalo. Thank you. That is my current approach. My issue is that it snap autoupgrades the installation to 1.17 which incompatible with our current app.
If you specify a channel during snap install you will be following the respective kubernetes version. For example if you do a sudo snap install microk8s --classic --channel=1.15/stable your snap will never refresh to 1.17. A refresh may get you from 1.15.9 to 1.15.10 but you will never go to 1.17.