├── CHARTER.md ├── LICENSE ├── MINUTES.md ├── README.md └── doctrine └── 02-04-2021-DistributedOperatingSystemVoid.md /CHARTER.md: -------------------------------------------------------------------------------- 1 | # Common Operating System Interface Charter 2 | 3 | The goal of this document is to clearly define what this project claims responsibility over. 4 | 5 | ### COSI Specification 6 | 7 | The project will maintain a community driven API that will represent the boundaries between a distributed orchestration system (such as Kubernetes) and the underlying userland and kernel (such as Linux). 8 | 9 | ### COSI Implementations 10 | 11 | The project will selectively host and mantain various tools that implement the COSI spec. These tools will be independently maintained, and each will declare it's own scope of work and release cycle. 12 | 13 | ### COSI Open Source 14 | 15 | Having a safe, effective, open, transparent, and commercial free experience is our number one value. As COSI evolves as a project, we may consider some sort of formal project governance. For now we trust commercially motivated contributions to maintain a clear and transparent set of ethics. 16 | 17 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | Apache License 3 | Version 2.0, January 2004 4 | http://www.apache.org/licenses/ 5 | 6 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 7 | 8 | 1. Definitions. 9 | 10 | "License" shall mean the terms and conditions for use, reproduction, 11 | and distribution as defined by Sections 1 through 9 of this document. 12 | 13 | "Licensor" shall mean the copyright owner or entity authorized by 14 | the copyright owner that is granting the License. 15 | 16 | "Legal Entity" shall mean the union of the acting entity and all 17 | other entities that control, are controlled by, or are under common 18 | control with that entity. For the purposes of this definition, 19 | "control" means (i) the power, direct or indirect, to cause the 20 | direction or management of such entity, whether by contract or 21 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 22 | outstanding shares, or (iii) beneficial ownership of such entity. 23 | 24 | "You" (or "Your") shall mean an individual or Legal Entity 25 | exercising permissions granted by this License. 26 | 27 | "Source" form shall mean the preferred form for making modifications, 28 | including but not limited to software source code, documentation 29 | source, and configuration files. 30 | 31 | "Object" form shall mean any form resulting from mechanical 32 | transformation or translation of a Source form, including but 33 | not limited to compiled object code, generated documentation, 34 | and conversions to other media types. 35 | 36 | "Work" shall mean the work of authorship, whether in Source or 37 | Object form, made available under the License, as indicated by a 38 | copyright notice that is included in or attached to the work 39 | (an example is provided in the Appendix below). 40 | 41 | "Derivative Works" shall mean any work, whether in Source or Object 42 | form, that is based on (or derived from) the Work and for which the 43 | editorial revisions, annotations, elaborations, or other modifications 44 | represent, as a whole, an original work of authorship. For the purposes 45 | of this License, Derivative Works shall not include works that remain 46 | separable from, or merely link (or bind by name) to the interfaces of, 47 | the Work and Derivative Works thereof. 48 | 49 | "Contribution" shall mean any work of authorship, including 50 | the original version of the Work and any modifications or additions 51 | to that Work or Derivative Works thereof, that is intentionally 52 | submitted to Licensor for inclusion in the Work by the copyright owner 53 | or by an individual or Legal Entity authorized to submit on behalf of 54 | the copyright owner. For the purposes of this definition, "submitted" 55 | means any form of electronic, verbal, or written communication sent 56 | to the Licensor or its representatives, including but not limited to 57 | communication on electronic mailing lists, source code control systems, 58 | and issue tracking systems that are managed by, or on behalf of, the 59 | Licensor for the purpose of discussing and improving the Work, but 60 | excluding communication that is conspicuously marked or otherwise 61 | designated in writing by the copyright owner as "Not a Contribution." 62 | 63 | "Contributor" shall mean Licensor and any individual or Legal Entity 64 | on behalf of whom a Contribution has been received by Licensor and 65 | subsequently incorporated within the Work. 66 | 67 | 2. Grant of Copyright License. Subject to the terms and conditions of 68 | this License, each Contributor hereby grants to You a perpetual, 69 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 70 | copyright license to reproduce, prepare Derivative Works of, 71 | publicly display, publicly perform, sublicense, and distribute the 72 | Work and such Derivative Works in Source or Object form. 73 | 74 | 3. Grant of Patent License. Subject to the terms and conditions of 75 | this License, each Contributor hereby grants to You a perpetual, 76 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 77 | (except as stated in this section) patent license to make, have made, 78 | use, offer to sell, sell, import, and otherwise transfer the Work, 79 | where such license applies only to those patent claims licensable 80 | by such Contributor that are necessarily infringed by their 81 | Contribution(s) alone or by combination of their Contribution(s) 82 | with the Work to which such Contribution(s) was submitted. If You 83 | institute patent litigation against any entity (including a 84 | cross-claim or counterclaim in a lawsuit) alleging that the Work 85 | or a Contribution incorporated within the Work constitutes direct 86 | or contributory patent infringement, then any patent licenses 87 | granted to You under this License for that Work shall terminate 88 | as of the date such litigation is filed. 89 | 90 | 4. Redistribution. You may reproduce and distribute copies of the 91 | Work or Derivative Works thereof in any medium, with or without 92 | modifications, and in Source or Object form, provided that You 93 | meet the following conditions: 94 | 95 | (a) You must give any other recipients of the Work or 96 | Derivative Works a copy of this License; and 97 | 98 | (b) You must cause any modified files to carry prominent notices 99 | stating that You changed the files; and 100 | 101 | (c) You must retain, in the Source form of any Derivative Works 102 | that You distribute, all copyright, patent, trademark, and 103 | attribution notices from the Source form of the Work, 104 | excluding those notices that do not pertain to any part of 105 | the Derivative Works; and 106 | 107 | (d) If the Work includes a "NOTICE" text file as part of its 108 | distribution, then any Derivative Works that You distribute must 109 | include a readable copy of the attribution notices contained 110 | within such NOTICE file, excluding those notices that do not 111 | pertain to any part of the Derivative Works, in at least one 112 | of the following places: within a NOTICE text file distributed 113 | as part of the Derivative Works; within the Source form or 114 | documentation, if provided along with the Derivative Works; or, 115 | within a display generated by the Derivative Works, if and 116 | wherever such third-party notices normally appear. The contents 117 | of the NOTICE file are for informational purposes only and 118 | do not modify the License. You may add Your own attribution 119 | notices within Derivative Works that You distribute, alongside 120 | or as an addendum to the NOTICE text from the Work, provided 121 | that such additional attribution notices cannot be construed 122 | as modifying the License. 123 | 124 | You may add Your own copyright statement to Your modifications and 125 | may provide additional or different license terms and conditions 126 | for use, reproduction, or distribution of Your modifications, or 127 | for any such Derivative Works as a whole, provided Your use, 128 | reproduction, and distribution of the Work otherwise complies with 129 | the conditions stated in this License. 130 | 131 | 5. Submission of Contributions. Unless You explicitly state otherwise, 132 | any Contribution intentionally submitted for inclusion in the Work 133 | by You to the Licensor shall be under the terms and conditions of 134 | this License, without any additional terms or conditions. 135 | Notwithstanding the above, nothing herein shall supersede or modify 136 | the terms of any separate license agreement you may have executed 137 | with Licensor regarding such Contributions. 138 | 139 | 6. Trademarks. This License does not grant permission to use the trade 140 | names, trademarks, service marks, or product names of the Licensor, 141 | except as required for reasonable and customary use in describing the 142 | origin of the Work and reproducing the content of the NOTICE file. 143 | 144 | 7. Disclaimer of Warranty. Unless required by applicable law or 145 | agreed to in writing, Licensor provides the Work (and each 146 | Contributor provides its Contributions) on an "AS IS" BASIS, 147 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 148 | implied, including, without limitation, any warranties or conditions 149 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 150 | PARTICULAR PURPOSE. You are solely responsible for determining the 151 | appropriateness of using or redistributing the Work and assume any 152 | risks associated with Your exercise of permissions under this License. 153 | 154 | 8. Limitation of Liability. In no event and under no legal theory, 155 | whether in tort (including negligence), contract, or otherwise, 156 | unless required by applicable law (such as deliberate and grossly 157 | negligent acts) or agreed to in writing, shall any Contributor be 158 | liable to You for damages, including any direct, indirect, special, 159 | incidental, or consequential damages of any character arising as a 160 | result of this License or out of the use or inability to use the 161 | Work (including but not limited to damages for loss of goodwill, 162 | work stoppage, computer failure or malfunction, or any and all 163 | other commercial damages or losses), even if such Contributor 164 | has been advised of the possibility of such damages. 165 | 166 | 9. Accepting Warranty or Additional Liability. While redistributing 167 | the Work or Derivative Works thereof, You may choose to offer, 168 | and charge a fee for, acceptance of support, warranty, indemnity, 169 | or other liability obligations and/or rights consistent with this 170 | License. However, in accepting such obligations, You may act only 171 | on Your own behalf and on Your sole responsibility, not on behalf 172 | of any other Contributor, and only if You agree to indemnify, 173 | defend, and hold each Contributor harmless for any liability 174 | incurred by, or claims asserted against, such Contributor by reason 175 | of your accepting any such warranty or additional liability. 176 | 177 | END OF TERMS AND CONDITIONS 178 | 179 | APPENDIX: How to apply the Apache License to your work. 180 | 181 | To apply the Apache License to your work, attach the following 182 | boilerplate notice, with the fields enclosed by brackets "[]" 183 | replaced with your own identifying information. (Don't include 184 | the brackets!) The text should be enclosed in the appropriate 185 | comment syntax for the file format. We also recommend that a 186 | file or class name and description of purpose be included on the 187 | same "printed page" as the copyright notice for easier 188 | identification within third-party archives. 189 | 190 | Copyright 2021 The Common Operating System Interface Authors 191 | 192 | Licensed under the Apache License, Version 2.0 (the "License"); 193 | you may not use this file except in compliance with the License. 194 | You may obtain a copy of the License at 195 | 196 | http://www.apache.org/licenses/LICENSE-2.0 197 | 198 | Unless required by applicable law or agreed to in writing, software 199 | distributed under the License is distributed on an "AS IS" BASIS, 200 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 201 | See the License for the specific language governing permissions and 202 | limitations under the License. -------------------------------------------------------------------------------- /MINUTES.md: -------------------------------------------------------------------------------- 1 | # Minutes 2 | 3 | - [4/7/21](https://drive.google.com/file/d/17WL4DirR0V60Hy94PsuRSYU3qpJy1S5_/view?usp=sharing) 4 | - [4/14/21](https://drive.google.com/file/d/1O_gdQkaSk6AJT26zR5IDYLvPWzCzsgLN/view?usp=sharing) 5 | - [4/21/21](https://drive.google.com/file/d/1dm1kUC-J9ZC9jfQxkWkXg_pysHOVE0Q9/view?usp=sharing) 6 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # What is COSI? 2 | 3 | Welcome to the COSI (Common Operating System Interface) Project. 4 | 5 | COSI is an open source project that strives to offer a standardized interface for modern operating systems. 6 | 7 | The COSI project also houses concrete tooling that implements the Common Operating System Interface. 8 | 9 | ### Specification 10 | 11 | The COSI is a [collection of versioned specification files](https://github.com/cosi-project/specification) defined in protobuf. 12 | 13 | ### Weekly Calls 14 | 15 | We have weekly calls open to the public. 16 | Anyone is welcome to join, and conduct will be subject to project owners discretion. 17 | 18 | Call notes: [HackMD](https://hackmd.io/IXcDy0prSgia4lOH_e1xSA) 19 | 20 | Call recordings: [Minutes](./MINUTES.md) 21 | 22 | Call time: Wednesdays _9am Pacific (4pm GMT)_ 23 | 24 | ### Contributing 25 | 26 | COSI is a work in progress, and will potentially be adopting a Code of Conduct and official Contributing guidelines. 27 | 28 | ### License 29 | 30 | The COSI Project is licensed under the [Apache 2.0](https://github.com/cosi-project/community/blob/main/LICENSE) open source license. 31 | 32 | --- 33 | 34 | Despite the egregious dependency of having a GNU public license for kernel code, the project has adopted an Apache 2 license for the majority of our code. 35 | 36 | We are aware of the licensing constraints while working with the Linux kernel, and are dedicated to offering free and open source software within the legal boundaries of these constraints. 37 | 38 | -------------------------------------------------------------------------------- /doctrine/02-04-2021-DistributedOperatingSystemVoid.md: -------------------------------------------------------------------------------- 1 | # The Distributed Operating System Void 2 | 3 | Below this line is a literal translation of the original paper written by [Kris Nóva](https://nivenly.com) that addresses the Kubernetes specific problem with distributed operating systems. 4 | 5 | This serves as a concrete example and problem space for the COSI project to consider moving forward. 6 | 7 | --- 8 | 9 | Original Link: [nivenly.com/lib/2021-04-02-operating-system-inferface](https://nivenly.com/lib/2021-04-02-operating-system-interface/) 10 | 11 | ## Thesis 12 | 13 | Modern (circa 2021) UNIX based operating systems should be reimagined to support higher level workloads 14 | that are managed in a distributed environment, such as Kubernetes. 15 | 16 | The first step in progress towards this goal, is defining an interface. 17 | 18 | The Distributed Operating System Interface (`DOSi`) hopes to achieve this. 19 | 20 | # Problem Statement 21 | 22 | Over the past 7 years Kubernetes has grown in popularity. 23 | Kubernetes is built and managed on operating systems optimized for isolated workloads. 24 | Kubernetes mutates operating system level features, concerns, and services. 25 | Some of these services (CNI, Kubelet, Container Runtime, etc) are paramount for Kubernetes to run. 26 | 27 | I believe there should be a clear communication and management interface between Kubernetes and the underlying operating system. 28 | 29 | This interface does not exist, therefore an operating system implementation does not exist. 30 | 31 | # Vocabulary 32 | 33 | #### Distributed Operating System Interface 34 | 35 | (_DOSi_) the implementable boundary that is defined and optimized for higher level interaction with the operating system. 36 | 37 | Based on the definitions below, `DOSi` is the interface between `kubernetesland` and `userland`. 38 | 39 | - Alternatives (DOS, DOS API, DOSIX) 40 | 41 | ### Kernelland 42 | 43 | The computational space that exists below the system call API. 44 | 45 | ### Userland 46 | 47 | Also known as `userspace` in the Linux community, this is the operating system layer in which humans can engage. 48 | 49 | Everything above the kernel, that is not managed with Kubernetes. 50 | 51 | ### Kubernetesland 52 | 53 | Everything above `userland` that is managed with Kubernetes 54 | 55 | ### Node 56 | 57 | A kubernetes node. A single instance of a single operating system managing a machine. 58 | A node is a computer, that has a kubernetes-like layer running on top of the operating system. 59 | 60 | #### The Stack 61 | 62 | The combined layers of `kubernetesland`, `userland`, and `kerneland` 63 | 64 | # Summary 65 | 66 | I hope to define a clear interface between `kubernetesland` and `userland` that is complimentary to existing interfaces (CNI, CRI, CSI, OCI). 67 | While also considering the clear void that the sum of these existing interfaces do not address. 68 | In particular management, and security of the operating system and it's components as a whole. 69 | 70 | 71 | Below, find benefits of defining this interface. 72 | 73 | 74 | ### Benefits 75 | 76 | - Implementation, control, and management of the non-existent `kubernetes` and `node` security boundary. 77 | - Clearly defined management of `node` level services and configuration. 78 | - Finite set of use cases, and capabilities required from an operating system to run Kubernetes. 79 | - This will define the touch points between an operating system and Kubernetes, thus outlining which operating system features are critical. 80 | - EX: Do we need POSIX compliant user/group management? Or will Linux capabilities suffice? 81 | - Management of required `node` level services can be safely controlled from `kubernetesland` 82 | - EX: CNI mutations 83 | - EX: Privileged DaemonSets for mutating a host 84 | - EX: Kernel security controls (Seccomp, SELinux, eBPF, Auth, User Management) 85 | - EX: Storage providers interacting with the host 86 | 87 | # Prior Art 88 | 89 | It is obvious that there is prior art in the following `node` level services. 90 | There are fundamental flaws, and voids in what the existing interfaces assume. 91 | 92 | ### Network (CNI) 93 | 94 | Official [Container Networking Interface](https://github.com/containernetworking/cni) standard. 95 | 96 | - CNI defines the container networking API surface/shape for interacting with networking plugins [via the container runtime](https://github.com/containernetworking/cni/blob/master/SPEC.md#section-2-execution-protocol) in `userland`. 97 | - CNI does not solve *how* to install and mutate a CNI service in `userland` from a `kubernetesland` perspective. 98 | - CNI is [required by a container runtime](https://github.com/containernetworking/cni/blob/master/SPEC.md#overview-1), however it is assumed this is installed from `kubernetesland`. This is a paradox. 99 | - CNI assumes access to `userland` and more importantly access (and permission) to `fork(2)` and `execve(2)` 100 | - CNI does not solve *how* access is managed, or acquired. 101 | - CNI does not offer a standardized way of reporting, measuring, or limiting resources in `kubernetesland`. 102 | 103 | ### Storage (CSI) 104 | 105 | Official [Container Storage Interface](https://github.com/container-storage-interface/spec) standard. 106 | 107 | - CSI defines the container storage API surface/shape for interfacing with block and file storage drivers in `userland`. 108 | - More information on [CSI drivers](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/) 109 | - More information on [Kubelet device registration and plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 110 | - CSI does not solve *how* to install or manage block or file storage drivers. 111 | - The Kubelet plugin system does NOT solve how to install or manage Kubelet plugins from Kubernetes. 112 | - [Access to the Kubelet API server is required](https://v1-18.docs.kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-registration) to interact with the exposed registration service. 113 | - CSI (via the Kubelet registration endpoint and logic) can set limitations and provide status updates in `kubernetesland`. 114 | 115 | 116 | ### Runtime (Compute) (CRI/OCI) 117 | 118 | Official [Container Runtime Interface](https://github.com/kubernetes/cri-api) API. 119 | Official [Open Container Interface](https://github.com/opencontainers/runtime-spec) standard. 120 | - Official [Open Container Image Spec](https://github.com/opencontainers/image-spec) 121 | 122 | CRI is a implementation of OCI. 123 | The main difference is scope, in which case OCI also defines the [open container image spec](https://github.com/opencontainers/image-spec). 124 | 125 | 126 | - OCI and CRI define the container runtime API surface/shape for interfacing with container runtime "engines" from `userland`. 127 | - OCI also defines the API surface/shape and interface for packaging container images 128 | - Container runtimes are tightly coupled with Linux features, and therefor are tightly coupled with the operating system. 129 | - Container runtimes manage permissions, storage, and networking in different ways. 130 | - Container runtimes are tightly coupled with `storage` and `networking`. 131 | - Container runtimes do not define *how* they are installed or managed. 132 | 133 | # The Void 134 | 135 | There are several `userland` components that are not considered from a management perspective. 136 | 137 | Below are demonstrable questions that technically have answers. 138 | I hope to challenge the existing answers to these questions with DOSi. 139 | 140 | ### Demonstrable Questions 141 | 142 | - How is my container network defined? 143 | - How are my storage drivers defined? 144 | - How is my container runtime defined? 145 | - Which container runtime will I use? 146 | - How will I upgrade my container runtime? 147 | - Which clients have access to my container runtime? 148 | - How do I mutate my network configuration in `userland`? 149 | - How do I mutate my network configuration in `kubernetesland`? 150 | - How do I mutate kernel configuration? 151 | - eBPF 152 | - Kernel modules 153 | - IPTables 154 | - Seccomp filters and Seccomp policy 155 | - Namespace sharing 156 | - Linux capabilities 157 | - How can I read kernel runtime values? 158 | 159 | # Concrete use cases 160 | 161 | Below are some high level examples of concrete use cases that would directly benefit from having a standardized distributed operating system level interface (DOSi). 162 | 163 | ### Patching openssh 164 | 165 | In 2020 [CVE-2020-15778](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15778) was announced which allows command injection via `scp` using the `scp.c` function `toremote()` in the `OpenSSH` library. 166 | 167 | What is the existing story to update the `userland` libraries? 168 | How would `kubernetesland` be impacted by this update? 169 | 170 | ### Managing Access Control and Security Software 171 | 172 | Below find concrete examples of security software that will span `kubernetesland`, `userland`, and `kernelland`. 173 | Currently, there is no clearly (or safely) defined way to manage or mutate these concerns from a single control plane. 174 | 175 | - Seccomp policy 176 | - Pod Security Policy 177 | - Kubernetes Admissions Control Policy 178 | - Falco runtime security 179 | - AppArmor Policy 180 | 181 | ### Package Management 182 | 183 | Any `userland` level package is traditionally managed on a per instance basis and is managed via `userland`. 184 | Furthermore, the kernel, operating system, and operating system dependencies also need to be managed. 185 | 186 | ### Interprocess Communications 187 | 188 | What does the IPC namespace look like for distributed computing? 189 | 190 | How will multiple `userland` and `kubernetesland` applications manage: 191 | 192 | - mTLS 193 | - service discovery 194 | - routing 195 | - network policy and firewall controls 196 | - TCP packet level authentication 197 | - SPIRE/SPIFFE 198 | 199 | #### Storage Drivers 200 | 201 | By design `kubernetesland` and `userland` security boundaries are violated when a storage driver is mutated from `kubernetesland`. 202 | Furthermore this communication needs to be addressed holistically. 203 | 204 | Fundamentally there are multiple node level concerns that would potentially need to be mutated from `kubernetesland`. 205 | 206 | # Conclusion 207 | 208 | There is a service management, registry, and discovery void for `userland` level concerns. 209 | There is a distributed communications void for `userland` and `kubernetesland` interprocess communications. 210 | There is a security void for `userland` as we have learned that we depend on mutating `userland` from `kubernetesland`. 211 | There is inconsistency in the main `userland` pillars of management (storage, networking, runtime) 212 | 213 | ### DOSi 214 | 215 | By defining a clear interface for an operating system running in a distributed environment we take the first step into claiming complete control over `userland` in Kubernetes, instead of partial control of pillars of the operating system as we see it today. 216 | 217 | --- 218 | 219 | # Open Considerations 220 | 221 | - Should the DOS interface consider the [POSIX IEEE standard](https://standards.ieee.org/project/1003_1.html)? 222 | - _more_: [POSIX Wikipedia](https://en.wikipedia.org/wiki/POSIX) 223 | 224 | --------------------------------------------------------------------------------