These partitions are reserved and cannot be modified.
-The one expection to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
+The one exception to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
Managing any other block device can be done via the blockd service.
diff --git a/docs/components/index.xml b/docs/components/index.xml
index 9b16371fd..0f0e2433d 100644
--- a/docs/components/index.xml
+++ b/docs/components/index.xml
@@ -86,7 +86,7 @@ To make this work, we needed an out-of-band tool for managing the nodes. In an i
https://dianemo.autonomy.io/components/blockd/Dianemo comes with a reserved block device with three partitions:
- an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one expection to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
+ an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one exception to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
diff --git a/docs/components/init/index.html b/docs/components/init/index.html
index e3c2ecf71..2fcfefff4 100644
--- a/docs/components/init/index.html
+++ b/docs/components/init/index.html
@@ -191,8 +191,15 @@
@@ -263,7 +270,7 @@ But, in the real world, this does not happen.
We still need a way to handle operational scenarios that may arise.
The osd daemon provides a way to do just that.
-Based on the Principle of Least Privilege, osd provides operational value for cluster administrations by providing an API for node management.
+Based on the Principle of Least Privilege, osd provides operational value for cluster administrators by providing an API for node management.
diff --git a/docs/components/proxyd/index.html b/docs/components/proxyd/index.html
index cd588628f..7c00a766b 100644
--- a/docs/components/proxyd/index.html
+++ b/docs/components/proxyd/index.html
@@ -191,8 +191,15 @@
In this section we will discuss the configuration of a Dianemo node.
+
In this section, we will step through the configuration of a Dianemo based Kubernetes cluster.
+There are three major components we will configure:
+
+
+
osd and osctl
+
the master nodes
+
the worker nodes
+
diff --git a/docs/configuration/index.xml b/docs/configuration/index.xml
index 9d0a7bec8..64d530362 100644
--- a/docs/configuration/index.xml
+++ b/docs/configuration/index.xml
@@ -12,12 +12,25 @@
- Control Plane
- https://dianemo.autonomy.io/configuration/controlplane/
+ osd
+ https://dianemo.autonomy.io/configuration/osd/
+ Sat, 03 Nov 2018 17:14:49 -0700
+
+ https://dianemo.autonomy.io/configuration/osd/
+ 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.
+
+
+
+ Masters
+ https://dianemo.autonomy.io/configuration/masters/
Mon, 29 Oct 2018 19:40:55 -0700
- https://dianemo.autonomy.io/configuration/controlplane/
- version: "" security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} identity: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} kubernetes: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} networking: os: {} kubernetes: {} services: kubeadm: init: type: initial etcdMemberName: etcd-1 containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: MasterConfiguration clusterName: example bootstrapTokens: - token: abcdef.0123456789abcdef ttl: 0s kubeProxy: config: ipvs: scheduler: lc mode: ipvs networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 trustd: username: example password: example You can generate the PKI resources and inject them into the configuration with osctl.
+ https://dianemo.autonomy.io/configuration/masters/
+ Configuring master nodes in a Dianemo Kubernetes cluster is a two part process:
+ configuring the Dianemo specific options and configuring the Kubernetes specific options To get started, create a YAML file we will use in the following steps:
+touch <node-name>.yaml Configuring Dianemo Injecting the Dianemo PKI Using osctl, and our output from the PKI instructions, inject the generated PKI into the configuration file:
+osctl inject os --crt <organization>.
@@ -26,7 +39,9 @@
Mon, 29 Oct 2018 19:40:55 -0700https://dianemo.autonomy.io/configuration/workers/
- version: "" security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} networking: os: {} kubernetes: {} services: kubeadm: containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: NodeConfiguration token: abcdef.0123456789abcdef discoveryTokenAPIServers: - ${MASTER_IP}:443 discoveryTokenCACertHashes: - sha256:${CA_CERT_HASH} trustd: username: example password: example endpoints: - ${MASTER_IP}
+ 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 version: "" security: os: ca: crt: <base 64 encoded root public certificate> services: kubeadm: configuration: | apiVersion: kubeadm.
diff --git a/docs/configuration/controlplane/index.html b/docs/configuration/masters/index.html
similarity index 68%
rename from docs/configuration/controlplane/index.html
rename to docs/configuration/masters/index.html
index 3b701da9a..6e1166324 100644
--- a/docs/configuration/controlplane/index.html
+++ b/docs/configuration/masters/index.html
@@ -189,10 +189,17 @@
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:
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 Dianemo.
+
+
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:
+
+
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.
+
+
+
+
Generating the Identity Certificates
+
+
Now that we have our root CA, we must create certificates that identify the node.
+As the cluster owner, run:
+
+
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:
+
+
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:
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.
diff --git a/docs/index.json b/docs/index.json
index c5064e0d0..6ff4f86b1 100644
--- a/docs/index.json
+++ b/docs/index.json
@@ -1 +1 @@
-[{"categories":null,"contents":"The kernel included with Dianemo is configured according to the recommendations outlined in the Kernel Self Protection Project (KSSP).\n","permalink":"https://dianemo.autonomy.io/components/kernel/","tags":null,"title":"kernel"},{"categories":null,"contents":"A common theme throughout the design of Dianemo is minimalism. We believe strongly in the UNIX philosophy that each program should do one job well. The init included in Dianemo is one example of this.\nWe wanted to create a focused init that had one job - run Kubernetes. There simply is no mechanism in place to do anything else.\nTo accomplish this, we must address real world operations needs like:\n Orchestration around creating a highly available control plane Log retrieval Restarting system services Rebooting a node and more In the following sections we will take a closer look at how these needs are addressed, and how services managed by init are designed to enhance the Kubernetes experience.\n","permalink":"https://dianemo.autonomy.io/components/init/","tags":null,"title":"init"},{"categories":null,"contents":"At the heart of Dianemo is kubeadm, allowing it to harness the power of the official upstream bootstrap tool. By integrating with kubeadm natively, Dianemo stands to gain a strong community of users and developers already familiar with kubeadm.\n","permalink":"https://dianemo.autonomy.io/components/kubeadm/","tags":null,"title":"kubeadm"},{"categories":null,"contents":"Security is one of the highest priorities within Autonomy. To run a Kubernetes cluster a certain level of trust is required to operate a cluster. For example, orchestrating the bootstrap of a highly available control plane requires the distribution of sensitive PKI data.\nTo that end, we created trustd. Based on the concept of a Root of Trust, trustd is a simple daemon responsible for establishing trust within the system. Once trust is established, various methods become available to the trustee. It can, for example, accept a write request from another node to place a file on disk.\nWe imagine that the number available methods will grow as Dianemo gets tested in the real world.\n","permalink":"https://dianemo.autonomy.io/components/trustd/","tags":null,"title":"trustd"},{"categories":null,"contents":"Highly available Kubernetes clusters are crucial for production quality clusters. The proxyd component is a simple yet powerful reverse proxy that adapts to where Dianemo is employed and provides load balancing across all API servers.\n","permalink":"https://dianemo.autonomy.io/components/proxyd/","tags":null,"title":"proxyd"},{"categories":null,"contents":"Dianemo is unique in that it has no concept of host-level access. There are no shells installed. No ssh daemon. Only what is required to run Kubernetes. Furthermore, there is no way to run any custom processes on the host level.\nTo make this work, we needed an out-of-band tool for managing the nodes. In an ideal world, the system would be self-healing and we would never have to touch it. But, in the real world, this does not happen. We still need a way to handle operational scenarios that may arise.\nThe osd daemon provides a way to do just that. Based on the Principle of Least Privilege, osd provides operational value for cluster administrations by providing an API for node management.\n","permalink":"https://dianemo.autonomy.io/components/osd/","tags":null,"title":"osd"},{"categories":null,"contents":"The osctl CLI is the client to the osd service running on every node. With it you can do things like:\n retrieve container logs restart a service reset a node reboot a node retrieve kernel logs generate pki resources inject data into node configuration files ","permalink":"https://dianemo.autonomy.io/components/osctl/","tags":null,"title":"osctl"},{"categories":null,"contents":"Dianemo comes with a reserved block device with three partitions:\n an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one expection to this is that the DATA partition will be resized automatically in the init process to the maximum size possible. Managing any other block device can be done via the blockd service.\n","permalink":"https://dianemo.autonomy.io/components/blockd/","tags":null,"title":"blockd"},{"categories":null,"contents":"First, create the AMI:\ndocker run \\ --rm \\ --volume $HOME/.aws/credentials:/root/.aws/credentials \\ --env AWS_DEFAULT_PROFILE=${PROFILE} \\ --env AWS_DEFAULT_REGION=${REGION} \\ autonomy/dianemo:latest ami -var regions=${COMMA_SEPARATED_LIST_OF_REGIONS} Once the AMI is created, you can now start an EC2 instance using the AMI ID. Provide the proper configuration as the instance\u0026rsquo;s user data.\n An official Terraform module is currently being developed, stay tuned!\n ","permalink":"https://dianemo.autonomy.io/examples/aws/","tags":null,"title":"AWS"},{"categories":null,"contents":"version: \u0026quot;\u0026quot; security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} identity: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} kubernetes: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} networking: os: {} kubernetes: {} services: kubeadm: init: type: initial etcdMemberName: etcd-1 containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: MasterConfiguration clusterName: example bootstrapTokens: - token: abcdef.0123456789abcdef ttl: 0s kubeProxy: config: ipvs: scheduler: lc mode: ipvs networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 trustd: username: example password: example You can generate the PKI resources and inject them into the configuration with osctl.\n ","permalink":"https://dianemo.autonomy.io/configuration/controlplane/","tags":null,"title":"Control Plane"},{"categories":null,"contents":"Dianemo is a modern Linux distribution designed to be secure, immutable, and minimal.\n","permalink":"https://dianemo.autonomy.io/dianemo/","tags":null,"title":"Dianemo"},{"categories":null,"contents":" Install the Master Node On the KVM host, install a master node to an available block device:\ndocker run \\ --rm \\ --privileged \\ --volume /dev:/dev \\ autonomy/dianemo:latest image -b /dev/sda -f -p bare-metal -u http://${IP}:8080/master.yaml http://${IP}:8080/master.yaml should be reachable by the VM and contain a valid master configuration file.\n virt-install \\ -n master \\ --description \u0026quot;Kubernetes master node.\u0026quot; \\ --os-type=Linux \\ --os-variant=generic \\ --virt-type=kvm \\ --cpu=host \\ --ram=4096 \\ --vcpus=2 \\ --disk path=/dev/sdc \\ --network bridge=br0,model=e1000,mac=52:54:00:A8:4C:E1 \\ --graphics none \\ --boot hd \\ --rng /dev/random Install a Worker Node Similarly, install a worker node to an available block device:\ndocker run \\ --rm \\ --privileged \\ --volume /dev:/dev \\ autonomy/dianemo:latest image -b /dev/sdb -f -p bare-metal -u http://${IP}:8080/worker.yaml http://${IP}:8080/worker.yaml should be reachable by the VM and contain a valid worker configuration file.\n virt-install \\ -n master \\ --description \u0026quot;Kubernetes worker node.\u0026quot; \\ --os-type=Linux \\ --os-variant=generic \\ --virt-type=kvm \\ --cpu=host \\ --ram=4096 \\ --vcpus=2 \\ --disk path=/dev/sdc \\ --network bridge=br0,model=e1000,mac=52:54:00:B9:5D:F2 \\ --graphics none \\ --boot hd \\ --rng /dev/random ","permalink":"https://dianemo.autonomy.io/examples/kvm/","tags":null,"title":"KVM"},{"categories":null,"contents":"version: \u0026quot;\u0026quot; security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} networking: os: {} kubernetes: {} services: kubeadm: containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: NodeConfiguration token: abcdef.0123456789abcdef discoveryTokenAPIServers: - ${MASTER_IP}:443 discoveryTokenCACertHashes: - sha256:${CA_CERT_HASH} trustd: username: example password: example endpoints: - ${MASTER_IP} ","permalink":"https://dianemo.autonomy.io/configuration/workers/","tags":null,"title":"Workers"}]
\ No newline at end of file
+[{"categories":null,"contents":" 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).\nCluster 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.\nCluster 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 Dianemo.\nConfiguring osd To configure osd, we will need:\n 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.\nGenerating the Root CA The root CA can be generated by running:\nosctl gen ca --hours \u0026lt;hours\u0026gt; --organization \u0026lt;organization\u0026gt; The cluster owner should store the generated private key (\u0026lt;organization\u0026gt;.key) in a safe place, that only other cluster owners have access to. The public certificate (\u0026lt;organization\u0026gt;.crt) should be made available to cluster administrators because, as we will see shortly, it is required to configure osctl.\nNote: The --rsa flag should not be specified for the generation of the osd CA.\n Generating the Identity Certificates Now that we have our root CA, we must create certificates that identify the node. As the cluster owner, run:\nosctl gen key --name \u0026lt;node-name\u0026gt; osctl gen csr --ip \u0026lt;node-ip\u0026gt; --key \u0026lt;node-name\u0026gt;.key osctl gen crt --hours \u0026lt;hours\u0026gt; --ca \u0026lt;organization\u0026gt; --csr \u0026lt;node-name\u0026gt;.csr --name \u0026lt;node-name\u0026gt; Repeat this process for each node that will participate as a master.\nConfiguring osctl To configure osctl, we will need:\n 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.\nGenerating the User Certificate The user requesting cluster administration access runs the following:\nosctl gen key --name \u0026lt;user\u0026gt; osctl gen csr --ip 127.0.0.1 --key \u0026lt;user\u0026gt;.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:\nosctl gen crt --hours \u0026lt;hours\u0026gt; --ca \u0026lt;organization\u0026gt; --csr \u0026lt;user\u0026gt;.csr --name \u0026lt;user\u0026gt; The generated certificate is then sent to the requesting user using a secure channel.\nThe Configuration File With all the above steps done, the new cluster administrator can now create the configuration file for osctl.\ncat \u0026lt;organization\u0026gt;.crt | base64 cat \u0026lt;user\u0026gt;.crt | base64 cat \u0026lt;user\u0026gt;.key | base64 Now, create ~/.dianemo/config with the following contents:\ncontext: \u0026lt;context\u0026gt; contexts: \u0026lt;context\u0026gt;: target: \u0026lt;node-ip\u0026gt; ca: \u0026lt;base 64 encoded root public certificate\u0026gt; crt: \u0026lt;base 64 encoded user public certificate\u0026gt; key: \u0026lt;base 64 encoded user private key\u0026gt; ","permalink":"https://dianemo.autonomy.io/configuration/osd/","tags":null,"title":"osd"},{"categories":null,"contents":"The kernel included with Dianemo is configured according to the recommendations outlined in the Kernel Self Protection Project (KSSP).\n","permalink":"https://dianemo.autonomy.io/components/kernel/","tags":null,"title":"kernel"},{"categories":null,"contents":" Configuring master nodes in a Dianemo Kubernetes cluster is a two part process:\n configuring the Dianemo specific options and configuring the Kubernetes specific options To get started, create a YAML file we will use in the following steps:\ntouch \u0026lt;node-name\u0026gt;.yaml Configuring Dianemo Injecting the Dianemo PKI Using osctl, and our output from the PKI instructions, inject the generated PKI into the configuration file:\nosctl inject os --crt \u0026lt;organization\u0026gt;.crt --key \u0026lt;organization\u0026gt;.key \u0026lt;node-name\u0026gt;.yaml osctl inject identity --crt \u0026lt;node-name\u0026gt;.crt --key \u0026lt;node-name\u0026gt;.key \u0026lt;node-name\u0026gt;.yaml You should see the following fields populated:\nsecurity: os: ca: crt: \u0026lt;base 64 encoded root public certificate\u0026gt; key: \u0026lt;base 64 encoded root private key\u0026gt; identity: crt: \u0026lt;base 64 encoded identity public certificate\u0026gt; key: \u0026lt;base 64 encoded identity private key\u0026gt; ... Configuring trustd Each master node participates as a Root of Trust in the cluster. The responsibilities of trustd include:\n 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 \u0026lt;node-name\u0026gt;.yaml, add the follwing:\nsecurity: ... services: ... trustd: username: \u0026lt;username\u0026gt; password: \u0026lt;password\u0026gt; ... Configuring Kubernetes Generating the Root CA To create the root CA for the Kubernetes cluster, run:\nosctl gen ca --rsa --hours \u0026lt;hours\u0026gt; --organization \u0026lt;kubernetes-organization\u0026gt; Note: The --rsa flag is required for the generation of the Kubernetes CA.\n Injecting the Kubernetes PKI Using osctl, inject the generated PKI into the configuration file:\nosctl inject kubernetes --crt \u0026lt;kubernetes-organization\u0026gt;.crt --key \u0026lt;kubernetes-organization\u0026gt;.key \u0026lt;node-name\u0026gt;.yaml You should see the following fields populated:\nsecurity: ... kubernetes: ca: crt: \u0026lt;base 64 encoded root public certificate\u0026gt; key: \u0026lt;base 64 encoded root private key\u0026gt; ... Configuring Kubeadm The configuration of the kubeadm service is done in two parts:\n supplying the Dianemo specific options supplying the kubeadm InitConfiguration Dianemo Specific Options services: ... kubeadm: init: type: initial etcdMemberName: \u0026lt;member-name\u0026gt; ... Kubeadm Specific Options services: ... kubeadm: ... configuration: | apiVersion: kubeadm.k8s.io/v1alpha3 kind: InitConfiguration ... ... See the official documentation for the options available in InitConfiguration.\n ","permalink":"https://dianemo.autonomy.io/configuration/masters/","tags":null,"title":"Masters"},{"categories":null,"contents":"A common theme throughout the design of Dianemo is minimalism. We believe strongly in the UNIX philosophy that each program should do one job well. The init included in Dianemo is one example of this.\nWe wanted to create a focused init that had one job - run Kubernetes. There simply is no mechanism in place to do anything else.\nTo accomplish this, we must address real world operations needs like:\n Orchestration around creating a highly available control plane Log retrieval Restarting system services Rebooting a node and more In the following sections we will take a closer look at how these needs are addressed, and how services managed by init are designed to enhance the Kubernetes experience.\n","permalink":"https://dianemo.autonomy.io/components/init/","tags":null,"title":"init"},{"categories":null,"contents":"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.\nWe need to specify:\n the osd public certificate trustd credentials and endpoints and a kubeadm JoinConfiguration version: \u0026quot;\u0026quot; security: os: ca: crt: \u0026lt;base 64 encoded root public certificate\u0026gt; services: kubeadm: configuration: | apiVersion: kubeadm.k8s.io/v1alpha3 kind: JoinConfiguration ... trustd: username: \u0026lt;username\u0026gt; password: \u0026lt;password\u0026gt; endpoints: - \u0026lt;master-1\u0026gt; ... - \u0026lt;master-n\u0026gt; See the official documentation for the options available in InitConfiguration.\n ","permalink":"https://dianemo.autonomy.io/configuration/workers/","tags":null,"title":"Workers"},{"categories":null,"contents":"At the heart of Dianemo is kubeadm, allowing it to harness the power of the official upstream bootstrap tool. By integrating with kubeadm natively, Dianemo stands to gain a strong community of users and developers already familiar with kubeadm.\n","permalink":"https://dianemo.autonomy.io/components/kubeadm/","tags":null,"title":"kubeadm"},{"categories":null,"contents":"Security is one of the highest priorities within Autonomy. To run a Kubernetes cluster a certain level of trust is required to operate a cluster. For example, orchestrating the bootstrap of a highly available control plane requires the distribution of sensitive PKI data.\nTo that end, we created trustd. Based on the concept of a Root of Trust, trustd is a simple daemon responsible for establishing trust within the system. Once trust is established, various methods become available to the trustee. It can, for example, accept a write request from another node to place a file on disk.\nWe imagine that the number available methods will grow as Dianemo gets tested in the real world.\n","permalink":"https://dianemo.autonomy.io/components/trustd/","tags":null,"title":"trustd"},{"categories":null,"contents":"Highly available Kubernetes clusters are crucial for production quality clusters. The proxyd component is a simple yet powerful reverse proxy that adapts to where Dianemo is employed and provides load balancing across all API servers.\n","permalink":"https://dianemo.autonomy.io/components/proxyd/","tags":null,"title":"proxyd"},{"categories":null,"contents":"Dianemo is unique in that it has no concept of host-level access. There are no shells installed. No ssh daemon. Only what is required to run Kubernetes. Furthermore, there is no way to run any custom processes on the host level.\nTo make this work, we needed an out-of-band tool for managing the nodes. In an ideal world, the system would be self-healing and we would never have to touch it. But, in the real world, this does not happen. We still need a way to handle operational scenarios that may arise.\nThe osd daemon provides a way to do just that. Based on the Principle of Least Privilege, osd provides operational value for cluster administrators by providing an API for node management.\n","permalink":"https://dianemo.autonomy.io/components/osd/","tags":null,"title":"osd"},{"categories":null,"contents":"The osctl CLI is the client to the osd service running on every node. With it you can do things like:\n retrieve container logs restart a service reset a node reboot a node retrieve kernel logs generate pki resources inject data into node configuration files ","permalink":"https://dianemo.autonomy.io/components/osctl/","tags":null,"title":"osctl"},{"categories":null,"contents":"Dianemo comes with a reserved block device with three partitions:\n an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one exception to this is that the DATA partition will be resized automatically in the init process to the maximum size possible. Managing any other block device can be done via the blockd service.\n","permalink":"https://dianemo.autonomy.io/components/blockd/","tags":null,"title":"blockd"},{"categories":null,"contents":"First, create the AMI:\ndocker run \\ --rm \\ --volume $HOME/.aws/credentials:/root/.aws/credentials \\ --env AWS_DEFAULT_PROFILE=${PROFILE} \\ --env AWS_DEFAULT_REGION=${REGION} \\ autonomy/dianemo:latest ami -var regions=${COMMA_SEPARATED_LIST_OF_REGIONS} Once the AMI is created, you can now start an EC2 instance using the AMI ID. Provide the proper configuration as the instance\u0026rsquo;s user data.\n An official Terraform module is currently being developed, stay tuned!\n ","permalink":"https://dianemo.autonomy.io/examples/aws/","tags":null,"title":"AWS"},{"categories":null,"contents":"Dianemo is a modern Linux distribution designed to be secure, immutable, and minimal.\n","permalink":"https://dianemo.autonomy.io/dianemo/","tags":null,"title":"Dianemo"},{"categories":null,"contents":" Install the Master Node On the KVM host, install a master node to an available block device:\ndocker run \\ --rm \\ --privileged \\ --volume /dev:/dev \\ autonomy/dianemo:latest image -b /dev/sda -f -p bare-metal -u http://${IP}:8080/master.yaml http://${IP}:8080/master.yaml should be reachable by the VM and contain a valid master configuration file.\n virt-install \\ -n master \\ --description \u0026quot;Kubernetes master node.\u0026quot; \\ --os-type=Linux \\ --os-variant=generic \\ --virt-type=kvm \\ --cpu=host \\ --ram=4096 \\ --vcpus=2 \\ --disk path=/dev/sdc \\ --network bridge=br0,model=e1000,mac=52:54:00:A8:4C:E1 \\ --graphics none \\ --boot hd \\ --rng /dev/random Install a Worker Node Similarly, install a worker node to an available block device:\ndocker run \\ --rm \\ --privileged \\ --volume /dev:/dev \\ autonomy/dianemo:latest image -b /dev/sdb -f -p bare-metal -u http://${IP}:8080/worker.yaml http://${IP}:8080/worker.yaml should be reachable by the VM and contain a valid worker configuration file.\n virt-install \\ -n master \\ --description \u0026quot;Kubernetes worker node.\u0026quot; \\ --os-type=Linux \\ --os-variant=generic \\ --virt-type=kvm \\ --cpu=host \\ --ram=4096 \\ --vcpus=2 \\ --disk path=/dev/sdc \\ --network bridge=br0,model=e1000,mac=52:54:00:B9:5D:F2 \\ --graphics none \\ --boot hd \\ --rng /dev/random ","permalink":"https://dianemo.autonomy.io/examples/kvm/","tags":null,"title":"KVM"}]
\ No newline at end of file
diff --git a/docs/index.xml b/docs/index.xml
index 3dbae0063..42004c027 100644
--- a/docs/index.xml
+++ b/docs/index.xml
@@ -6,11 +6,21 @@
Recent content on DianemoHugo -- gohugo.ioen-us
- Mon, 29 Oct 2018 19:40:55 -0700
+ Sat, 03 Nov 2018 17:14:49 -0700
+
+ osd
+ https://dianemo.autonomy.io/configuration/osd/
+ Sat, 03 Nov 2018 17:14:49 -0700
+
+ https://dianemo.autonomy.io/configuration/osd/
+ 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.
+
+
kernel
https://dianemo.autonomy.io/components/kernel/
@@ -20,6 +30,18 @@
The kernel included with Dianemo is configured according to the recommendations outlined in the Kernel Self Protection Project (KSSP).
+
+ Masters
+ https://dianemo.autonomy.io/configuration/masters/
+ Mon, 29 Oct 2018 19:40:55 -0700
+
+ https://dianemo.autonomy.io/configuration/masters/
+ Configuring master nodes in a Dianemo Kubernetes cluster is a two part process:
+ configuring the Dianemo specific options and configuring the Kubernetes specific options To get started, create a YAML file we will use in the following steps:
+touch <node-name>.yaml Configuring Dianemo Injecting the Dianemo PKI Using osctl, and our output from the PKI instructions, inject the generated PKI into the configuration file:
+osctl inject os --crt <organization>.
+
+
init
https://dianemo.autonomy.io/components/init/
@@ -31,6 +53,17 @@ We wanted to create a focused init that had one job - run Kubernetes. There simp
To accomplish this, we must address real world operations needs like:
+
+ Workers
+ https://dianemo.autonomy.io/configuration/workers/
+ Mon, 29 Oct 2018 19:40:55 -0700
+
+ https://dianemo.autonomy.io/configuration/workers/
+ 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 version: "" security: os: ca: crt: <base 64 encoded root public certificate> services: kubeadm: configuration: | apiVersion: kubeadm.
+
+
kubeadm
https://dianemo.autonomy.io/components/kubeadm/
@@ -86,7 +119,7 @@ To make this work, we needed an out-of-band tool for managing the nodes. In an i
https://dianemo.autonomy.io/components/blockd/Dianemo comes with a reserved block device with three partitions:
- an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one expection to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
+ an EFI System Partition (ESP) a ROOT partition mounted as read-only that contains the minimal set of binaries to operate system services and a DATA partion that is mounted as read/write at /var/run These partitions are reserved and cannot be modified. The one exception to this is that the DATA partition will be resized automatically in the init process to the maximum size possible.
@@ -101,15 +134,6 @@ docker run \ --rm \ --volume $HOME/.aws/credentials:/root/.aws/credentials \ --e
-
- Control Plane
- https://dianemo.autonomy.io/configuration/controlplane/
- Mon, 29 Oct 2018 19:40:55 -0700
-
- https://dianemo.autonomy.io/configuration/controlplane/
- version: "" security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} identity: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} kubernetes: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509} networking: os: {} kubernetes: {} services: kubeadm: init: type: initial etcdMemberName: etcd-1 containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: MasterConfiguration clusterName: example bootstrapTokens: - token: abcdef.0123456789abcdef ttl: 0s kubeProxy: config: ipvs: scheduler: lc mode: ipvs networking: dnsDomain: cluster.local podSubnet: 10.244.0.0/16 serviceSubnet: 10.96.0.0/12 trustd: username: example password: example You can generate the PKI resources and inject them into the configuration with osctl.
-
-
Dianemo
https://dianemo.autonomy.io/dianemo/
@@ -130,14 +154,5 @@ docker run \ --rm \ --privileged \ --volume /dev:/dev \ autonomy/dianemo:latest
virt-install \ -n master \ --description "Kubernetes master node." \ --os-type=Linux \ --os-variant=generic \ --virt-type=kvm \ --cpu=host \ --ram=4096 \ --vcpus=2 \ --disk path=/dev/sdc \ --network bridge=br0,model=e1000,mac=52:54:00:A8:4C:E1 \ --graphics none \ --boot hd \ --rng /dev/random Install a Worker Node Similarly, install a worker node to an available block device:
-
- Workers
- https://dianemo.autonomy.io/configuration/workers/
- Mon, 29 Oct 2018 19:40:55 -0700
-
- https://dianemo.autonomy.io/configuration/workers/
- version: "" security: os: ca: crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509} networking: os: {} kubernetes: {} services: kubeadm: containerRuntime: docker configuration: | apiVersion: kubeadm.k8s.io/v1alpha2 kind: NodeConfiguration token: abcdef.0123456789abcdef discoveryTokenAPIServers: - ${MASTER_IP}:443 discoveryTokenCACertHashes: - sha256:${CA_CERT_HASH} trustd: username: example password: example endpoints: - ${MASTER_IP}
-
-
\ No newline at end of file
diff --git a/docs/sitemap.xml b/docs/sitemap.xml
index 357291cac..fbb2e7a54 100644
--- a/docs/sitemap.xml
+++ b/docs/sitemap.xml
@@ -2,16 +2,31 @@
+
+ https://dianemo.autonomy.io/configuration/osd/
+ 2018-11-03T17:14:49-07:00
+
+
https://dianemo.autonomy.io/components/kernel/2018-10-29T19:40:55-07:00
+
+ https://dianemo.autonomy.io/configuration/masters/
+ 2018-10-29T19:40:55-07:00
+
+
https://dianemo.autonomy.io/components/init/2018-10-29T19:40:55-07:00
+
+ https://dianemo.autonomy.io/configuration/workers/
+ 2018-10-29T19:40:55-07:00
+
+
https://dianemo.autonomy.io/components/kubeadm/2018-10-29T19:40:55-07:00
@@ -57,11 +72,6 @@
2018-10-29T19:40:55-07:00
-
- https://dianemo.autonomy.io/configuration/controlplane/
- 2018-10-29T19:40:55-07:00
-
-
https://dianemo.autonomy.io/dianemo/2018-10-29T19:40:55-07:00
@@ -77,11 +87,6 @@
2018-10-29T19:40:55-07:00
-
- https://dianemo.autonomy.io/configuration/workers/
- 2018-10-29T19:40:55-07:00
-
-
https://dianemo.autonomy.io/categories/0
@@ -89,7 +94,7 @@
https://dianemo.autonomy.io/
- 2018-10-29T19:40:55-07:00
+ 2018-11-03T17:14:49-07:000
diff --git a/docs/tags/index.html b/docs/tags/index.html
index 87674ea3d..dfd032f13 100644
--- a/docs/tags/index.html
+++ b/docs/tags/index.html
@@ -191,8 +191,15 @@
diff --git a/src/docs/src/content/components/blockd.md b/src/docs/src/content/components/blockd.md
index 097c851bd..471866d16 100644
--- a/src/docs/src/content/components/blockd.md
+++ b/src/docs/src/content/components/blockd.md
@@ -2,6 +2,7 @@
title: "blockd"
date: 2018-10-30T09:16:35-07:00
draft: false
+weight: 80
menu:
main:
parent: 'components'
@@ -15,5 +16,5 @@ Dianemo comes with a reserved block device with three partitions:
- and a `DATA` partion that is mounted as read/write at `/var/run`
These partitions are reserved and cannot be modified.
-The one expection to this is that the `DATA` partition will be resized automatically in the `init` process to the maximum size possible.
+The one exception to this is that the `DATA` partition will be resized automatically in the `init` process to the maximum size possible.
Managing any other block device can be done via the `blockd` service.
diff --git a/src/docs/src/content/components/osd.md b/src/docs/src/content/components/osd.md
index 35d8d4714..04b71c35b 100644
--- a/src/docs/src/content/components/osd.md
+++ b/src/docs/src/content/components/osd.md
@@ -21,4 +21,4 @@ But, in the real world, this does not happen.
We still need a way to handle operational scenarios that may arise.
The `osd` daemon provides a way to do just that.
-Based on the Principle of Least Privilege, `osd` provides operational value for cluster administrations by providing an API for node management.
+Based on the Principle of Least Privilege, `osd` provides operational value for cluster administrators by providing an API for node management.
diff --git a/src/docs/src/content/configuration/_index.md b/src/docs/src/content/configuration/_index.md
index 7ad5ae102..dcb93b18f 100644
--- a/src/docs/src/content/configuration/_index.md
+++ b/src/docs/src/content/configuration/_index.md
@@ -4,4 +4,9 @@ date: 2018-10-29T19:40:55-07:00
draft: false
---
-In this section we will discuss the configuration of a Dianemo node.
+In this section, we will step through the configuration of a Dianemo based Kubernetes cluster.
+There are three major components we will configure:
+
+- `osd` and `osctl`
+- the master nodes
+- the worker nodes
diff --git a/src/docs/src/content/configuration/controlplane.md b/src/docs/src/content/configuration/controlplane.md
deleted file mode 100644
index 23ccc0b0e..000000000
--- a/src/docs/src/content/configuration/controlplane.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: "Control Plane"
-date: 2018-10-29T19:40:55-07:00
-draft: false
-menu:
- main:
- parent: 'configuration'
- weight: 10
----
-
-```yaml
-version: ""
-security:
- os:
- ca:
- crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509}
- key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509}
- identity:
- crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509}
- key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509}
- kubernetes:
- ca:
- crt: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509}
- key: ${BASE64_ENCODED_PEM_FORMATTED_PRIVATE_X509}
-networking:
- os: {}
- kubernetes: {}
-services:
- kubeadm:
- init:
- type: initial
- etcdMemberName: etcd-1
- containerRuntime: docker
- configuration: |
- apiVersion: kubeadm.k8s.io/v1alpha2
- kind: MasterConfiguration
- clusterName: example
- bootstrapTokens:
- - token: abcdef.0123456789abcdef
- ttl: 0s
- kubeProxy:
- config:
- ipvs:
- scheduler: lc
- mode: ipvs
- networking:
- dnsDomain: cluster.local
- podSubnet: 10.244.0.0/16
- serviceSubnet: 10.96.0.0/12
- trustd:
- username: example
- password: example
-```
-
-> You can generate the PKI resources and inject them into the configuration with [osctl]({{< relref "/components/osctl" >}}).
diff --git a/src/docs/src/content/configuration/masters.md b/src/docs/src/content/configuration/masters.md
new file mode 100644
index 000000000..451efe289
--- /dev/null
+++ b/src/docs/src/content/configuration/masters.md
@@ -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 Dianemo Kubernetes cluster is a two part process:
+
+- configuring the Dianemo specific options
+- and configuring the Kubernetes specific options
+
+To get started, create a YAML file we will use in the following steps:
+
+```bash
+touch .yaml
+```
+
+## Configuring Dianemo
+
+### Injecting the Dianemo PKI
+
+Using `osctl`, and our output from the [PKI]({{< ref "osd.md" >}}) instructions, inject the generated PKI into the configuration file:
+
+```bash
+osctl inject os --crt .crt --key .key .yaml
+osctl inject identity --crt .crt --key .key .yaml
+```
+
+You should see the following fields populated:
+
+```yaml
+security:
+ os:
+ ca:
+ crt:
+ key:
+ identity:
+ crt:
+ 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 `.yaml`, add the follwing:
+
+```yaml
+security:
+...
+services:
+ ...
+ trustd:
+ username:
+ password:
+ ...
+```
+
+## Configuring Kubernetes
+
+### Generating the Root CA
+
+To create the root CA for the Kubernetes cluster, run:
+
+```bash
+osctl gen ca --rsa --hours --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 .crt --key .key .yaml
+```
+
+You should see the following fields populated:
+
+```yaml
+security:
+ ...
+ kubernetes:
+ ca:
+ crt:
+ key:
+ ...
+```
+
+### Configuring Kubeadm
+
+The configuration of the `kubeadm` service is done in two parts:
+
+- supplying the Dianemo specific options
+- supplying the `kubeadm` `InitConfiguration`
+
+#### Dianemo Specific Options
+
+```yaml
+services:
+ ...
+ kubeadm:
+ init:
+ type: initial
+ etcdMemberName:
+ ...
+```
+
+#### 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`.
diff --git a/src/docs/src/content/configuration/osd.md b/src/docs/src/content/configuration/osd.md
new file mode 100644
index 000000000..4a430f025
--- /dev/null
+++ b/src/docs/src/content/configuration/osd.md
@@ -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 Dianemo.
+
+## 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 --organization
+```
+
+The cluster owner should store the generated private key (`.key`) in a safe place, that only other cluster owners have access to.
+The public certificate (`.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
+osctl gen csr --ip --key .key
+osctl gen crt --hours --ca --csr .csr --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
+osctl gen csr --ip 127.0.0.1 --key .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 --ca --csr .csr --name
+```
+
+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 .crt | base64
+cat .crt | base64
+cat .key | base64
+```
+
+Now, create `~/.dianemo/config` with the following contents:
+
+```yaml
+context:
+contexts:
+ :
+ target:
+ ca:
+ crt:
+ key:
+```
diff --git a/src/docs/src/content/configuration/workers.md b/src/docs/src/content/configuration/workers.md
index 1108a0db3..6e192e60c 100644
--- a/src/docs/src/content/configuration/workers.md
+++ b/src/docs/src/content/configuration/workers.md
@@ -2,35 +2,42 @@
title: "Workers"
date: 2018-10-29T19:40:55-07:00
draft: false
+weight: 30
menu:
main:
parent: 'configuration'
- weight: 20
+ 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: ${BASE64_ENCODED_PEM_FORMATTED_PUBLIC_X509}
-networking:
- os: {}
- kubernetes: {}
+ crt:
services:
kubeadm:
- containerRuntime: docker
configuration: |
- apiVersion: kubeadm.k8s.io/v1alpha2
- kind: NodeConfiguration
- token: abcdef.0123456789abcdef
- discoveryTokenAPIServers:
- - ${MASTER_IP}:443
- discoveryTokenCACertHashes:
- - sha256:${CA_CERT_HASH}
+ apiVersion: kubeadm.k8s.io/v1alpha3
+ kind: JoinConfiguration
+ ...
trustd:
- username: example
- password: example
+ username:
+ password:
endpoints:
- - ${MASTER_IP}
+ -
+ ...
+ -
```
+
+> See the official [documentation](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/) for the options available in `InitConfiguration`.
diff --git a/src/docs/src/themes/autonomy/layouts/shortcodes/note.html b/src/docs/src/themes/autonomy/layouts/shortcodes/note.html
new file mode 100644
index 000000000..f293cc918
--- /dev/null
+++ b/src/docs/src/themes/autonomy/layouts/shortcodes/note.html
@@ -0,0 +1,3 @@
+