fd044ee117
* Enable bootstrap token authentication on kube-apiserver * Generate the bootstrap.kubernetes.io/token Secret that may be used as a bootstrap token * Generate a bootstrap kubeconfig (with a bootstrap token) to be securely distributed to nodes. Each Kubelet will use the bootstrap kubeconfig to authenticate to kube-apiserver as `system:bootstrappers` and send a node-unique CSR for kube-controller-manager to automatically approve to issue a Kubelet certificate and kubeconfig (expires in 72 hours) * Add ClusterRoleBinding for bootstrap token subjects (`system:bootstrappers`) to have the `system:node-bootstrapper` ClusterRole * Add ClusterRoleBinding for bootstrap token subjects (`system:bootstrappers`) to have the csr nodeclient ClusterRole * Add ClusterRoleBinding for bootstrap token subjects (`system:bootstrappers`) to have the csr selfnodeclient ClusterRole * Enable NodeRestriction admission controller to limit the scope of Node or Pod objects a Kubelet can modify to those of the node itself * Ability for a Kubelet to delete its Node object is retained as preemptible nodes or those in auto-scaling instance groups need to be able to remove themselves on shutdown. This need continues to have precedence over any risk of a node deleting itself maliciously Security notes: 1. Issued Kubelet certificates authenticate as user `system:node:NAME` and group `system:nodes` and are limited in their authorization to perform API operations by Node authorization and NodeRestriction admission. Previously, a Kubelet's authorization was broader. This is the primary security motivation. 2. The bootstrap kubeconfig credential has the same sensitivity as the previous generated TLS client-certificate kubeconfig. It must be distributed securely to nodes. Its compromise still allows an attacker to obtain a Kubelet kubeconfig 3. Bootstrapping Kubelet kubeconfig's with a limited lifetime offers a slight security improvement. * An attacker who obtains the kubeconfig can likely obtain the bootstrap kubeconfig as well, to obtain the ability to renew their access * A compromised bootstrap kubeconfig could plausibly be handled by replacing the bootstrap token Secret, distributing the token to new nodes, and expiration. Whereas a compromised TLS-client certificate kubeconfig can't be revoked (no CRL). However, replacing a bootstrap token can be impractical in real cluster environments, so the limited lifetime is mostly a theoretical benefit. * Cluster CSR objects are visible via kubectl which is nice 4. Bootstrapping node-unique Kubelet kubeconfigs means Kubelet clients have more identity information, which can improve the utility of audits and future features Rel: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/ Rel: https://github.com/poseidon/terraform-render-bootstrap/pull/185 |
||
|---|---|---|
| .github | ||
| addons | ||
| aws | ||
| azure | ||
| bare-metal | ||
| digital-ocean | ||
| docs | ||
| google-cloud | ||
| CHANGES.md | ||
| CONTRIBUTING.md | ||
| DCO | ||
| LICENSE | ||
| mkdocs.yml | ||
| README.md | ||
| requirements.txt | ||
Typhoon 
Typhoon is a minimal and free Kubernetes distribution.
- Minimal, stable base Kubernetes distribution
- Declarative infrastructure and configuration
- Free (freedom and cost) and privacy-respecting
- Practical for labs, datacenters, and clouds
Typhoon distributes upstream Kubernetes, architectural conventions, and cluster addons, much like a GNU/Linux distribution provides the Linux kernel and userspace components.
Features 
- Kubernetes v1.18.2 (upstream)
- Single or multi-master, Calico or flannel networking
- On-cluster etcd with TLS, RBAC-enabled, network policy
- Advanced features like worker pools, preemptible workers, and snippets customization
- Ready for Ingress, Prometheus, Grafana, CSI, or other addons
Modules
Typhoon provides a Terraform Module for each supported operating system and platform.
Typhoon is available for Fedora CoreOS.
| Platform | Operating System | Terraform Module | Status |
|---|---|---|---|
| AWS | Fedora CoreOS | aws/fedora-coreos/kubernetes | stable |
| Azure | Fedora CoreOS | azure/fedora-coreos/kubernetes | alpha |
| Bare-Metal | Fedora CoreOS | bare-metal/fedora-coreos/kubernetes | beta |
| DigitalOcean | Fedora CoreOS | digital-ocean/fedora-coreos/kubernetes | alpha |
| Google Cloud | Fedora CoreOS | google-cloud/fedora-coreos/kubernetes | beta |
Typhoon is available for Flatcar Container Linux.
| Platform | Operating System | Terraform Module | Status |
|---|---|---|---|
| AWS | Flatcar Linux | aws/container-linux/kubernetes | stable |
| Azure | Flatcar Linux | azure/container-linux/kubernetes | alpha |
| Bare-Metal | Flatcar Linux | bare-metal/container-linux/kubernetes | stable |
| DigitalOcean | Flatcar Linux | digital-ocean/container-linux/kubernetes | alpha |
| Google Cloud | Flatcar Linux | google-cloud/container-linux/kubernetes | alpha |
Typhoon is available for CoreOS Container Linux (no updates after May 2020).
| Platform | Operating System | Terraform Module | Status |
|---|---|---|---|
| AWS | Container Linux | aws/container-linux/kubernetes | stable |
| Azure | Container Linux | azure/container-linux/kubernetes | alpha |
| Bare-Metal | Container Linux | bare-metal/container-linux/kubernetes | stable |
| Digital Ocean | Container Linux | digital-ocean/container-linux/kubernetes | beta |
| Google Cloud | Container Linux | google-cloud/container-linux/kubernetes | stable |
Documentation
- Docs
- Architecture concepts and operating systems
- Fedora CoreOS tutorials for AWS, Azure, Bare-Metal, DigitalOcean, and Google Cloud
- Flatcar Linux tutorials for AWS, Azure, Bare-Metal, DigitalOcean, and Google Cloud
Usage
Define a Kubernetes cluster by using the Terraform module for your chosen platform and operating system. Here's a minimal example:
module "yavin" {
source = "git::https://github.com/poseidon/typhoon//google-cloud/container-linux/kubernetes?ref=v1.18.2"
# Google Cloud
cluster_name = "yavin"
region = "us-central1"
dns_zone = "example.com"
dns_zone_name = "example-zone"
# configuration
ssh_authorized_key = "ssh-rsa AAAAB3Nz..."
# optional
worker_count = 2
worker_preemptible = true
}
# Obtain cluster kubeconfig
resource "local_file" "kubeconfig-yavin" {
content = module.yavin.kubeconfig-admin
filename = "/home/user/.kube/configs/yavin-config"
}
Initialize modules, plan the changes to be made, and apply the changes.
$ terraform init
$ terraform plan
Plan: 62 to add, 0 to change, 0 to destroy.
$ terraform apply
Apply complete! Resources: 62 added, 0 changed, 0 destroyed.
In 4-8 minutes (varies by platform), the cluster will be ready. This Google Cloud example creates a yavin.example.com DNS record to resolve to a network load balancer across controller nodes.
$ export KUBECONFIG=/home/user/.kube/configs/yavin-config
$ kubectl get nodes
NAME ROLES STATUS AGE VERSION
yavin-controller-0.c.example-com.internal <none> Ready 6m v1.18.2
yavin-worker-jrbf.c.example-com.internal <none> Ready 5m v1.18.2
yavin-worker-mzdm.c.example-com.internal <none> Ready 5m v1.18.2
List the pods.
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system calico-node-1cs8z 2/2 Running 0 6m
kube-system calico-node-d1l5b 2/2 Running 0 6m
kube-system calico-node-sp9ps 2/2 Running 0 6m
kube-system coredns-1187388186-zj5dl 1/1 Running 0 6m
kube-system coredns-1187388186-dkh3o 1/1 Running 0 6m
kube-system kube-apiserver-controller-0 1/1 Running 0 6m
kube-system kube-controller-manager-controller-0 1/1 Running 0 6m
kube-system kube-proxy-117v6 1/1 Running 0 6m
kube-system kube-proxy-9886n 1/1 Running 0 6m
kube-system kube-proxy-njn47 1/1 Running 0 6m
kube-system kube-scheduler-controller-0 1/1 Running 0 6m
Non-Goals
Typhoon is strict about minimalism, maturity, and scope. These are not in scope:
- In-place Kubernetes Upgrades
- Adding every possible option
- Openstack or Mesos platforms
Help
Ask questions on the IRC #typhoon channel on freenode.net.
Motivation
Typhoon powers the author's cloud and colocation clusters. The project has evolved through operational experience and Kubernetes changes. Typhoon is shared under a free license to allow others to use the work freely and contribute to its upkeep.
Typhoon addresses real world needs, which you may share. It is honest about limitations or areas that aren't mature yet. It avoids buzzword bingo and hype. It does not aim to be the one-solution-fits-all distro. An ecosystem of Kubernetes distributions is healthy.
Social Contract
Typhoon is not a product, trial, or free-tier. It is not run by a company, does not offer support or services, and does not accept or make any money. It is not associated with any operating system or platform vendor.
Typhoon clusters will contain only free components. Cluster components will not collect data on users without their permission.
Donations
Typhoon does not accept money donations. Instead, we encourage you to donate to one of these organizations to show your appreciation.
- DigitalOcean kindly provides credits to support Typhoon test clusters.