scottk/talos
1
0
Fork 0
mirror of https://github.com/lingble/talos.git synced 2025-12-09 00:55:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

chore: use buildkit for builds (#295)

Browse Source
This commit is contained in:
Andrew Rynhard
2018-12-19 22:22:05 -08:00
committed by GitHub
parent 3de43232dc
commit 72eb1b34f5
170 changed files with 647 additions and 2331 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
web/content/configuration/_index.md Normal file
View File

@@ -0,0 +1,12 @@
---
title: "Configuration"
date: 2018-10-29T19:40:55-07:00
draft: false
---
In this section, we will step through the configuration of a Talos based Kubernetes cluster.
There are three major components we will configure:
- `osd` and `osctl`
- the master nodes
- the worker nodes

136
web/content/configuration/masters.md Normal file
View File

@@ -0,0 +1,136 @@
---
title: "Masters"
date: 2018-10-29T19:40:55-07:00
draft: false
weight: 20
menu:
main:
parent: 'configuration'
weight: 20
---
Configuring master nodes in a Talos Kubernetes cluster is a two part process:
- configuring the Talos specific options
- and configuring the Kubernetes specific options
To get started, create a YAML file we will use in the following steps:
```bash
touch <node-name>.yaml
```
## Configuring Talos
### Injecting the Talos PKI
Using `osctl`, and our output from the `osd` configuration [documentation]({{< ref "osd.md" >}}), inject the generated PKI into the configuration file:
```bash
osctl inject os --crt <organization>.crt --key <organization>.key <node-name>.yaml
osctl inject identity --crt <node-name>.crt --key <node-name>.key <node-name>.yaml
```
You should see the following fields populated:
```yaml
security:
os:
ca:
crt: <base 64 encoded root public certificate>
key: <base 64 encoded root private key>
identity:
crt: <base 64 encoded identity public certificate>
key: <base 64 encoded identity private key>
...
```
### Configuring `trustd`
Each master node participates as a Root of Trust in the cluster.
The responsibilities of `trustd` include:
- certificate as a service
- and Kubernetes PKI distribution amongst master nodes
The auth done between `trustd` and a client is, for now, a simple username and password combination.
Having these credentials gives a client the power to request a certifcate that identifies itself.
In the `<node-name>.yaml`, add the follwing:
```yaml
security:
...
services:
...
trustd:
username: <username>
password: <password>
...
```
## Configuring Kubernetes
### Generating the Root CA
To create the root CA for the Kubernetes cluster, run:
```bash
osctl gen ca --rsa --hours <hours> --organization <kubernetes-organization>
```
{{% note %}}The `--rsa` flag is required for the generation of the Kubernetes CA. {{% /note %}}
### Injecting the Kubernetes PKI
Using `osctl`, inject the generated PKI into the configuration file:
```bash
osctl inject kubernetes --crt <kubernetes-organization>.crt --key <kubernetes-organization>.key <node-name>.yaml
```
You should see the following fields populated:
```yaml
security:
...
kubernetes:
ca:
crt: <base 64 encoded root public certificate>
key: <base 64 encoded root private key>
...
```
### Configuring Kubeadm
The configuration of the `kubeadm` service is done in two parts:
- supplying the Talos specific options
- supplying the `kubeadm` `InitConfiguration`
#### Talos Specific Options
```yaml
services:
...
kubeadm:
init:
type: initial
etcdMemberName: <member-name>
...
```
#### Kubeadm Specific Options
```yaml
services:
...
kubeadm:
...
configuration: |
apiVersion: kubeadm.k8s.io/v1alpha3
kind: InitConfiguration
...
...
```
> See the official [documentation](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/) for the options available in `InitConfiguration`.

111
web/content/configuration/osd.md Normal file
View File

@@ -0,0 +1,111 @@
---
title: "osd"
date: 2018-11-03T17:14:49-07:00
draft: false
weight: 10
menu:
main:
identifier: "osd-configuration"
parent: 'configuration'
weight: 10
---
The `osd` service enforces a high level of security by utilizing mutual TLS for authentication and authorization.
In this section we will configure mutual TLS by generating the certificates for the servers (`osd`) and clients (`osctl`).
### Cluster Owners
We recommend that the configuration of `osd` be performed by a cluster owner.
A cluster owner should be a person of authority within an organization.
Perhaps a director, manager, or senior member of a team.
They are responsible for storing the root CA, and distributing the PKI for authorized cluster administrators.
### Cluster Administrators
The authorization to use `osctl` should be granted to a person fit for cluster administration.
As a cluster administrator, the user gains access to the out-of-band management tools offered by Talos.
## Configuring `osd`
To configure `osd`, we will need:
- static IP addresses for each node that will participate as a master
- a root CA
- and identity certificates for each node participating as a master signed by the root CA
The following steps should be performed by a cluster owner.
### Generating the Root CA
The root CA can be generated by running:
```bash
osctl gen ca --hours <hours> --organization <organization>
```
The cluster owner should store the generated private key (`<organization>.key`) in a safe place, that only other cluster owners have access to.
The public certificate (`<organization>.crt`) should be made available to cluster administrators because, as we will see shortly, it is required to configure `osctl`.
{{% note %}}The `--rsa` flag should _not_ be specified for the generation of the `osd` CA.{{% /note %}}
### Generating the Identity Certificates
Now that we have our root CA, we must create certificates that identify the node.
As the cluster owner, run:
```bash
osctl gen key --name <node-name>
osctl gen csr --ip <node-ip> --key <node-name>.key
osctl gen crt --hours <hours> --ca <organization> --csr <node-name>.csr --name <node-name>
```
Repeat this process for each node that will participate as a master.
## Configuring `osctl`
To configure `osctl`, we will need:
- the root CA we generated above
- and a certificate signed by the root CA specific to the user
The process for setting up `osctl` is done in part between a cluster owner and a user requesting to become a cluster administrator.
### Generating the User Certificate
The user requesting cluster administration access runs the following:
```bash
osctl gen key --name <user>
osctl gen csr --ip 127.0.0.1 --key <user>.key
```
Now, the cluster owner must generate a certificate from the above CSR.
To do this, the user requesting access submits the CSR generated above to the cluster owner, and the cluster owner runs the following:
```bash
osctl gen crt --hours <hours> --ca <organization> --csr <user>.csr --name <user>
```
The generated certificate is then sent to the requesting user using a secure channel.
### The Configuration File
With all the above steps done, the new cluster administrator can now create the configuration file for `osctl`.
```bash
cat <organization>.crt | base64
cat <user>.crt | base64
cat <user>.key | base64
```
Now, create `~/.talos/config` with the following contents:
```yaml
context: <context>
contexts:
<context>:
target: <node-ip>
ca: <base 64 encoded root public certificate>
crt: <base 64 encoded user public certificate>
key: <base 64 encoded user private key>
```

43
web/content/configuration/workers.md Normal file
View File

@@ -0,0 +1,43 @@
---
title: "Workers"
date: 2018-10-29T19:40:55-07:00
draft: false
weight: 30
menu:
main:
parent: 'configuration'
weight: 30
---
Configuring the worker nodes is much more simple in comparison to configuring the master nodes.
Using the `trustd` API, worker nodes submit a `CSR`, and, if authenticated, receive a valid `osd` certificate.
Similarly, using a `kubeadm` token, the node joins an existing cluster.
We need to specify:
- the `osd` public certificate
- `trustd` credentials and endpoints
- and a `kubeadm` `JoinConfiguration`
```yaml
version: ""
security:
os:
ca:
crt: <base 64 encoded root public certificate>
services:
kubeadm:
configuration: |
apiVersion: kubeadm.k8s.io/v1alpha3
kind: JoinConfiguration
...
trustd:
username: <username>
password: <password>
endpoints:
- <master-1>
...
- <master-n>
```
> See the official [documentation](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/) for the options available in `JoinConfiguration`.