Comments (5)
Added a few comments to the deck. Ideally everything related to hardware should be handled through Kubernetes (avoiding privileged access from a CNF)
from testsuite.
There is a long way to go though. Like GTP kernel tunnels need privileged access, and I bet XDP and eBPF are still not on the Device Plugin landscape. But I agree - avoid direct access to anything. A bit of concern is tht support for 3.10 kernel, but well ... that may drop at some pointl.
from testsuite.
I updated the title, more tests could be added, rewording the last question is recommended
from testsuite.
There is indeed a long way to go, but i'd rather try to set the bar high from the beginning. The GTP tunnels "only" requires net_admin capabilities, but that is still more access to the underlying system than I would consider cloud native :)
from testsuite.
A few thoughts based on some quick research and evaluation:
- No container (or pod) should have direct access to hardware
- No container (or pod) should run as privileged
- Any volume used by a pod must be separated from the host or other pods in the deployment
- Hardware resources must be requested through Kubernetes (native or plugin based)
If, for whatever reason, direct hardware or privileged access is needed, this must be done through containers using images specifically made for this purpose. These images must enforce restrictions necessary to ensure general security and proper separation between pods and between the host and pods.
Volume separation is already fairly well handled in Kubernetes, as documented here. Access to sensitive directories on the host must be limited by default, but potentially made possible through a set of managed images provided as part of the infrastructure (more details on this below)
Looking at the analysis already done by @denverwilliams here, the tools mentioned can also be used to help with conformance wrt. hardware.
Falco provides auditing that can help ensure pods stay conformant with requirements on hardware access. It also allows (partial/full) whitelisting of trusted images, that can be used to provide some level of direct hardware access to pods.
Another area of interest is networking. By default Kubernetes provides limited capabilities for network access to containers and pods. There are several ways of adding additional interfaces to containers, some require direct hardware access (physical ports), others host access (e.g. netlink). Another way to handle networks and interfaces is through the use of CNI plugins, and there is an ongoing discussion happening on the TUG mailing list.
Some hardware is available as resources through Kubernetes, e.g. CPU and memory (hugepages). Information about these can be found here. Similary, pods can be constrained to a sub-set of nodes using various concepts available through Kubernetes. More information about this can be found here
from testsuite.
Related Issues (20)
- [Feature] Separate manifest installation mode from helm
- [Feature] Join installation modes HelmChart and HelmDirectory
- [Feature] Redesign oran_e2_connection test HOT 1
- [Feature] redesign observability tracing test
- [Feature] Redesign workload_resource_test function HOT 2
- [MAINTENANCE] Remove and exchange duplicate test for privileged containers
- [MAINTENANCE] update stable/envoy HOT 3
- [MAINTENANCE] Align cert set with "Certification 2.0 beta" - reduce it to 19 essential tests
- Test Documentation Updates
- [EPIC] Redesign CNF installation process
- [Feature] CNF installation (1), Implement new config format
- [MAINTENANCE] Delete or redesign of CNF configuration HOT 1
- [Feature] Redesign manifest generation for helm charts
- [Feature] CNF installation (4), Create and use common manifest
- [Feature] CNF Installation (2.1), Config format transformer for older version
- [Feature] Should we remove "ip_addresses" test?
- [Feature] Install cnfs into system-wide directory
- [Feature] CNF Installation (3), Switch to new config usage
- [BUG] Image size spec test using protected repo is not working HOT 1
- [Feature] CNF Installation (2.2), New config format generation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from testsuite.