20bfd69780
* Build Kubelet container images internally and publish to Quay and Dockerhub (new) as an alternative in case of registry outage or breach * Use our infra to provide single and multi-arch (default) Kublet images for possible future use * Docs: Show how to use alternative Kubelet images via snippets and a systemd dropin (builds on #737) Changes: * Update docs with changes to Kubelet image building * If you prefer to trust images built by Quay/Dockerhub, automated image builds are still available with unique tags (albeit with some limitations): * Quay automated builds are tagged `build-{short_sha}` (limit: only amd64) * Dockerhub automated builts are tagged `build-{tag}` and `build-master` (limit: only amd64, no shas) Links: * Kubelet: https://github.com/poseidon/kubelet * Docs: https://typhoon.psdn.io/topics/security/#container-images * Registries: * quay.io/poseidon/kubelet * docker.io/psdn/kubelet
3.7 KiB
Security
Typhoon aims to be minimal and secure. We're running it ourselves after all.
Overview
Kubernetes
- etcd with peer-to-peer and client-auth TLS
- Kubelets TLS bootstrap certificates (72 hours)
- Generated TLS certificate (365 days) for admin
kubeconfig - NodeRestriction is enabled to limit Kubelet authorization
- Role-Based Access Control is enabled. Apps must define RBAC policies for API access
- Workloads run on worker nodes only, unless they tolerate the master taint
- Kubernetes Network Policy and Calico NetworkPolicy support 1
Hosts
- Container Linux auto-updates are enabled
- Hosts limit logins to SSH key-based auth (user "core")
- SELinux enforcing mode 2
Platform
- Cloud firewalls limit access to ssh, kube-apiserver, and ingress
- No cluster credentials are stored in Matchbox (used for bare-metal)
- No cluster credentials are stored in Digital Ocean metadata
- Cluster credentials are stored in AWS metadata (for ASGs)
- Cluster credentials are stored in Azure metadata (for scale sets)
- Cluster credentials are stored in Google Cloud metadata (for managed instance groups)
- No account credentials are available to Digital Ocean droplets
- No account credentials are available to AWS EC2 instances (no IAM permissions)
- No account credentials are available to Azure instances (no IAM permissions)
- No account credentials are available to Google Cloud instances (no IAM permissions)
Precautions
Typhoon limits exposure to many security threats, but it is not a silver bullet. As usual,
- Do not run untrusted images or accept manifests from strangers
- Do not give untrusted users a shell behind your firewall
- Define network policies for your namespaces
Container Images
Typhoon uses upstream container images (where possible) and upstream binaries.
!!! note
Kubernetes releases kubelet as a binary for distros to package, either as a DEB/RPM on traditional distros or as a container image for container-optimized operating systems.
Typhoon packages the upstream Kubelet and its dependencies as a container image. Builds fetch the upstream Kubelet binary and verify its checksum.
The Kubelet image is published to Quay.io and Dockerhub.
- quay.io/poseidon/kubelet (official)
- docker.io/psdn/kubelet (fallback)
Two tag styles indicate the build strategy used.
- Typhoon internal infra publishes single and multi-arch images (e.g.
v1.18.3,v1.18.3-amd64,v1.18.3-arm64,v1.18.3-2-g23228e6-amd64,v1.18.3-2-g23228e6-arm64) - Quay and Dockerhub automated builds publish verifiable images (e.g.
build-SHAon Quay,build-TAGon Dockerhub)
The Typhoon-built Kubelet image is used as the official image. Automated builds provide an alternative image for those preferring to trust images built by Quay/Dockerhub (albeit lacking multi-arch). To use the fallback registry or an alternative tag, see customization.
Disclosures
If you find security issues, please email dghubble at gmail. If the issue lies in upstream Kubernetes, please inform upstream Kubernetes as well.