Comments (5)
Maybe this is a bit off topic but just to let you know: with the latest release with @petersutter we decided to remove the kubectl
X IaaS cli
version matrix because it was generating too many security vulnerabilities that had to be triaged separately.
Additionally, we thought that using 1.22.7
should be enough for now - even though it is not recommended to be used with older k8s
versions due to version skew it still does the job pretty well. And we would only add additional versions if we see it becoming a problem.
As for the IaaS clients, we noticed that on older versions of the ops-toolbelt
some of the clients weren't even installed properly. Since no-one complained we thought that nobody is using those images and decided to remove them. And since gardenctl
was removed but there is still no gardenctl-v2
using IaaS clis from the docker image and having to configure them becomes more of a chore.
Not sure if we could somehow label and deprecate the old images.
from ops-toolbelt.
On the Kubernetes version:
I find it incomprehensible to add and then remove that feature again, especially because there are incompatibilities and we were already criticised for this by our end users/had problems ourselves (I at least had). Was that the source of security vulnerabilities? Can we then find a better way to deal with it? We also support the old Kubernetes versions in Gardener - so what's the issue here with kubectl
if there was one?
On the IaaS CLIs:
Naturally, most of us have the CLIs already installed locally. Also, interactions are rarely required (so, I am not insisting or whatever). But when we require the CLIs and are under time pressure, this should be the most convenient (=fastest) way to get to the right clients right away. Also, during ops, people shy away and rather escalate the issue to the next support level instead of taking a look themselves. Making it even harder for them, will not help improve the situation. Was that the source of security vulnerabilities?
On gardenctl(-v2):
I never really understood why I would need gardenctl
within the ops-toolbelt. What's the use case? At the time I am launching an ops pod, I have already targeted it, no? It's the one thing that should make use of the ops-toolbelt, not the other way around.
On cleaning up the registry:
I don't understand. One opens the GCR and deletes the images. Done. Where is the problem (other than first making sure, the old stuff is no longer referenced, as suggested)?
from ops-toolbelt.
Anyway, if you want to throw away everything again, then so be it (no veto or whatever from my side - though I have to say, that I find the kubectl
decision completely incomprehensible, especially for web terminals), but let me then know which is the right image now and please clean up the mess in GCR. All this back and forth makes me dizzy.
from ops-toolbelt.
but let me then know which is the right image
There is only one image left, which is eu.gcr.io/gardener-project/gardener/ops-toolbelt
, that is updated with the latest
tag. We mentioned it as breaking change in the release notes https://github.com/gardener/ops-toolbelt/releases/tag/0.17.0.
and please clean up the mess in GCR
Usually I'm reluctant to delete anything from the registry, but sure we can do so as I doubt it was ever used internally. However we don't know if it was used outside SAP or not..
I find it incomprehensible to add and then remove that feature again
The built images weren't even used in the dashboard (for the webterminal feature). #50 was started but the dashboard side was never built and we do not have it on our roadmap as of now - if it's not contributed. Looking back we shouldn't have merged #50 before the feature on the dashboard side was not in sight. We also never saw any issues reported regarding the version skew of kubectl
.
It's the sheer amount of images that we build that is the problem in case vulnerabilites are found. Usually those are found in the ubuntu base image or in the common components and then we need to take a look at all the findings for all the images that we build.
I never really understood why I would need gardenctl within the ops-toolbelt. What's the use case? At the time I am launching an ops pod, I have already targeted it, no?
If you have gardenctl configured in your ops-toolbelt it would be possible to configure the infra-clis (gardenctl provider-env
). Not sure how it would work the other way around.
from ops-toolbelt.
Well, thank you, but that's not nice. The kubectl
skew is a problem. That's already bad enough.
As for the vulnerabilities: we may have many images, but they all stem/are built from the same base image that will in most cases contain the vulnerability, so the fix is exactly the same (one-time fix and rerun/republish, whether there is a matrix or not).
Anyway, if we don't want to improve / get back to where we once were and/or have no time anyway, then let's close the ticket. I cannot mentally click that button. ;-)
from ops-toolbelt.
Related Issues (20)
- install `k9s` on demand HOT 2
- Dependency Dashboard
- Wrong cert path is used for `etcdctl`
- Hardcoded `etcd_host` is used as precalculated argument for `etcdctl --endpoints` HOT 1
- adding kubetail to aggregate logs from multiple pods HOT 2
- Add ping utility HOT 2
- Bash prompt errors when mounting /hostroot HOT 12
- Provide Trimmed-Down Images per Infrastructure and Kubernetes Version HOT 13
- Add possibility to add tolerations to the ops-pod script HOT 1
- Set explicit CLI versions for reproducible builds HOT 2
- wireguard and iptables HOT 7
- Add nerdctl (instead of crictl) HOT 10
- a test issue, will close after done HOT 1
- [Bug] Container Image ARM64 Incompatibility
- alias k does not auto-complete
- Only support one kubectl version and remove all images containing infra-clis HOT 1
- After introduction of "matrix images", launch script not adapted
- install_k9s is broken for k9s >=0.27.0
- Switching default namespace of ops-pod to 'kube-system' HOT 1
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 ops-toolbelt.