Is microk8s considered secure enough for 'production' use?

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.

Thanks in advance for your thoughts!

1 Like

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.

1 Like

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.

1 Like

I am using Kubernetes on GCP. I am not exposed to Mini or MicroK8s however sharing link which might help you.

You can find more information on data encryption in Kubernetes in the official docs: Encrypting Secret Data at Rest - Kubernetes

Hi @tombull,

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].

[1] https://github.com/ktsakalozos/microk8s.io/blob/docs/ports-rework/docs/ports.md
[2] https://github.com/ktsakalozos/microk8s.io/blob/docs/ports-rework/docs/release-channels.md

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.

Since MicroK8s is a snap you can set a convenient time when during which you want updates to land. Have a look at https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--controlling-updates

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.

1 Like

In that case you can snap download the .snap package and install it as if it is local or you can install a snap proxy store to control all updates. See https://forum.snapcraft.io/t/announcing-snap-store-proxy-beta/4666