jiebi/CodeConvo huggingface dataset:
3 July 2020 [x] Two weeks soak end date: 20 July 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get the server version (hits api path /version) Check that the major version is current Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen was Merge but the merge was reversed by Issue and Test grid restarted.
Reopened this issue. <detailsIn response to : /reopen was Merge but the merge was reversed by Issue and Test grid restarted. </details
Automatic retest and Merge again
CVSS Rating: In typical clusters: medium (5.4) In clusters where API server insecure port has not been disabled: high (8.8) A security issue was discovered in which allows adjacent hosts to reach TCP and UDP services bound to running on the node or in the node's network namespace. For example, if a cluster administrator runs a TCP service on a node that listens on , because of this bug, that service would be potentially reachable by other hosts on the same LAN as the node, or by containers running on the same node as the service. If the example service on port required no additional authentication (because it assumed that only other localhost processes could reach it), then it could be vulnerable to attacks that make use of this bug. The Kubernetes API Server's default insecure port setting causes the API server to listen on where it will accept requests without authentication. Many Kubernetes installers explicitly disable the API Server's insecure port, but in clusters where it is not disabled, an attacker with access to another system on the same LAN or with control of a container running on the master may be able to reach the API server and execute arbitrary API requests on the cluster. This port is deprecated, and will be removed in Kubernetes v1.20. You may be vulnerable if: You are running a vulnerable version (see below) Your cluster nodes run in an environment where untrusted hosts share the same layer 2 domain (i.e. same LAN) as nodes Your cluster allows untrusted pods to run containers with (the Kubernetes default is to allow this capability). Your nodes (or hostnetwork pods) run any localhost-only services which do not require any further authentication. To list services that are potentially affected, run the following commands on nodes: - On a master node, an lsof entry like this indicates that the API server may be listening with an insecure port: kubelet/kube-proxy v1.18.0-1.18.3 kubelet/kube-proxy v1.17.0-1.17.6 kubelet/kube-proxy <=1.16.10 Prior to upgrading, this vulnerability can be mitigated by manually adding an iptables rule on nodes. This rule will reject traffic to 127.0.0.1 which does not originate on the node. Additionally, if your cluster does not already have the API Server insecure port disabled, we strongly suggest that you disable it.
Add the following flag to your kubernetes API server command line: Packets on the wire with an IPv4 destination in the range 127.0.0.0/8 and a layer-2 destination MAC address of a node may indicate that an attack is targeting this vulnerability. Although the issue is caused by , the current fix for the issue is in (although future versions may have the fix in instead). We recommend updating both and to be sure the issue is addressed. The following versions contain the fix: kubelet/kube-proxy master - fixed by kubelet/kube-proxy v1.18.4+ - fixed by kubelet/kube-proxy v1.17.7+ - fixed by kubelet/kube-proxy v1.16.11+ - fixed by To upgrade, refer to the documentation: This issue was originally raised in issue which details how the sets which causes the system not to reject traffic to localhost which originates on other hosts. IPv6-only services that bind to a address are not affected. There may be additional attack vectors possible in addition to those fixed by and its cherry-picks. For those attacks to succeed, the target service would need to be UDP and the attack could only rely upon sending UDP datagrams since it wouldn't receive any replies. Finally, the target node would need to have reverse-path filtering disabled for an attack to have any effect. Work is ongoing to determine whether and how this issue should be fixed. See for up-to-date status on this issue. This vulnerability was reported by János Kövér, Ericsson with additional impacts reported by Rory McCune, NCC Group and Yuval Avrahami and Ariel Zelivansky, Palo Alto Networks. /area security /kind bug /committee product-security /sig network /sig node /area kubelet
For insecure port removal:
The original announcement contained an error. The announcement makes it sound like upgrading kube-proxy will address the issue, but that is incorrect. I have edited the issue summary to add the following paragraph in the "Fixed Versions" section: Additionally, I have changed the components in listed versions to say kubelet/kube-proxy instead of kube-proxy.
Could you add numerical CVSS scores to these? "High" is too vague, frequently varies from vendor to vendor. I can calculate a score from the vector myself, but adding the score would save us some work...
Edited.
Also, the vector scores are clickable and will show the CVSS scores too.
To be clear, this is fixed in v1.18.4+, v1.17.7+, and v1.16.11+ correct?
Right. Sorry if the extra paragraph in "Fixed Versions" made that unclear.
Got it. Thank you!
So just to be sure, this wouldn't be a problem in an EKS cluster running in its own VPC, right? (assuming no untrusted hosts on the same VPC)
Are all the conditions listed under , a logical AND ?
Edit: after more testing, I think is indeed required
The attack can be done from any pod with (this is still K8S default), so you might not be safe. a more accurate title: "Node setting allows to bypass localhost boundary"
We believe that of the four conditions, you might be affected if (1 and (2 or 3) and 4) are true for your cluster. Sorry that it's not super clear from the text. Trying and failing to convey info concisely and with precision makes me glad that I'm in software, not law.
Isn't this broadly fixed by ? We're discussing better answers and options for deployment, too, but I am curious what the close-condition for this bug is?
I made a typo in the issue description saying that this is addressed by instead of . I'll edit it now. Sorry about that. Yes, this is mostly fixed by . I marked this as closed due to that PR fixing the majority of security issues caused by the setting. We can re-open if people think that we should address the remaining case that talks about.
Sorry, folks. I thought that this issue was already closed. Maybe that makes my response above to less confusing.
Yes, this being open was one of the major points of confusion for us. Appreciate the clarification
/label official-cve-feed (Related to )
In CPU usage went up significantly compared to It consumes more than one core even when there's no significant logging load on the node. Two changes between those version: CC
Ruby by default is single-core, so anything over that is likely introduced by the changes. But we'd need to investigate to make sure.
Can you please disable monitoring and see whether this is the problem?
I meant can you ...
Was going to do this, yes
Built container manually without prometheus plugin, still consumes 1.7 cpu
Can you please find the difference then?
Used new image with the old configuration (), still 1.7 cores It seems like a problem with the new image for some reason. FYI
What can consume 1.7 cores with the same configuration on a different machine? How to debug this?
Does this mean all components are same, ruby version, plugins and configuration settings? What are the differences between old and new image? OS or other parts are also different?
There are at least the following changer Ubuntu Trusty -Debian Jessie td-agent package -manually installed embedded ruby -ruby 2.1 embedded gems -fixed version gems from Gemfile embedded libjemalloc - I understand that it's a lot of changes and I'm going to narrow the problem down, the main question is where to look and how to debug to speed this process up?
If this is not fixed before Monday we will revert . cc
Only and should be reverted, not
No, we want to revert migration to the new base image. The changes to extract configuration into env var/config map should preserve. This mean that the revert might not be straightforward.
I think our backup option is to switch back to using td-agent package, not reverting whole change, because is also about security and we don't want to revert that I will check whether that helps
Thanks for investigating this! I have a couple comments: The full package diff can be found here: The first thing I would look at is whether the ruby version makes a difference. I believe td-agent was using 2.3 The main benefit of is actually not using td-agent, since the td-agent package includes lots of stuff we don't use (e.g. rails). Maybe if we need to fallback we could manually remove those extra packages. I'll poke around in the container and see if anything jumps out.
Thanks for the comments, they totally make sense. Also, thanks for the diff. Thanks!
Actually td-agent was using ruby 2.1:
A manual search through commenting out parts of the config file revealed that removing the systemd config solves the issue: I'll play around with the systemd libraries and see if I can figure out what's going on here.
Still investigating, but I think this may be a regression in the fluent-plugin-systemd library between version 0.0.5 (old image) and 0.0.7 (new image). I realized the diff I linked above was not in sync with the version that was actually pushed (). That diff is here, and accurately reflects the change in the systemd library:
Confirmed this is a regression in (0.0.6 does not have the problem). Fortunately 0.0.7 only has a single commit, I'll file an issue on the plugin. In the meantime, I'll send a PR to pin fluent-plugin-systemd to 0.0.6.
Thanks a huge lot for investigating and fixing this!
Reopening to track the version bump.
Good investigation. Latest systemd plugin uses and it seems to cause busy loop like problem.
Hi I just released that should fix this issue.
Thanks! And thanks to who already included it into our image :)
Yeah thanks your too fast for me :)
Thank you a lot for the investigation.
Is this a BUG REPORT or FEATURE REQUEST?: Bug Report /kind bug What happened: improved disk eviction testing to make it more precise. For example, it expects a pod which uses 299 Mb of disk not to be evicted if it sets its limit to 300 Mi. As shown on , this test passes for all OS distributions except CoreOS. I have ruled out an issue with the storage driver and backing filesystem since both COS and CoreOS use overlay backed by extfs. What you expected to happen: I expected the pod using 299Mb not to be evicted when its limit is 300 Mb. I expected not to see this event: How to reproduce it (as minimally and precisely as possible): The container runs this command to use 299Mb: Each iteration writes 1Mb to disk, producing a total of 299 Mb of disk usage. The pod has set to 300Mi. The test has the LocalStorageCapacityIsolation feature gate enabled. Anything else we need to know?: This may be a discrepancy in the (which we use to measure container disk usage) or , which is used by the test to write exact quantities of disk.
/sig node
cc can you take a look at this after thanksgiving?
I bumped the coreos image... going to see if it clears up the flake
It appears the root filesystem is being included in the disk space calculation . Do you think the coreos image might be slightly larger than the other images under test?
One more code snippet that is interesting:
thats the container's root filesystem
correct. the feature appears to add and compare to the quota: The reproducible steps do not take into account the rootfs space. If the quota is set to 300Mi, then the under loop count would have to take into account the rootfs space to not exceed the limit. I do not see anywhere in the tests or the reproduce steps this part of the calculation.
The refers only to the writable layer of the container, and excludes base (image) layers. With the provided command, the only files that are in the container's rootfs are the ones written by the command, and should amount to 299Mb. Additionally, the container does not write any logs (through stdout), so that value should be 0.
I ran a quick test on a vm with the current image, and found that both and correctly wrote and measured disk space correctly. I also tested as it inside a container, and verified that we are measuring the container's writable layer correctly. My guess now is that it has something to do with how we calculate disk usage by logging with journald. I am looking into it
Actually, the previous comment was incorrect. When I ran the test, I found that each file was 1028 kb instead of 1024 kb, which resulted in the command writing 300.3 Mb instead of 299 Mb. I will change the test to require slightly less precision. This appears to be because an empty file in coreos takes up 4 kb. Test this by running . On other OS we test on, empty files use 0 kb. This is what accounts for the difference.
I tracked down an issue to the dd call. The stdout and stderr need a redirect to /dev/null to suppress the following messages: Problem Line: Fix:
I PRed that fix and changed it to stderr, since the other tests seem to use stderr.
leaving this open until we get a green run
I'll continue to test locally to see if I find anything else.
opened PR with the help of and CoreOS defaults to using the actual size instead of the apprent size.
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I was writing a variant of clock.FakeClock, and noticed a couple of bugs in . Look at the pointer comparison in --- the two pointers will never be equal, but the author clearly expected equality when is the index of the fakeClockWaiter corresponding to the fakeTimer. The two pointers will never be equal because one is a pointer into the fakeClock's slice while the other pointer is to a field of the . The consequence of this bug is that the Stop function is ineffective. Also, determines the returned value based on the original copy of the waiter, which --- being a copy --- did not get updated if/when the waiter fired. Note also that does not exercise FakeClock::NewTimer at all. What you expected to happen: I expected FakeClock Timers to work properly. How to reproduce it (as minimally and precisely as possible): Use the TestFakeTimer func introduced in Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
The fake timer's Reset() method also does not work correctly.
Kubernetes 1.27 with feature gate enabled and disabled, a rebooted node is not able to re-start pods that were running there before the reboot. The node reports in Pod events: The Pod should start just fine. On Kubernetes 1.27: NewVolumeManagerReconstruction feature gate. a StatefulSet that uses a volume. -reboot the node which runs the StatefulSet Pod. The reason is that kubelet's VolumeManager reconstructs the volume as uncertain during startup and it uses a provisional outer volume name for it, because it has not seen the API server and Pods in it yet. This provisional volume ID is then used in ActualStateOfWorld forever. While kubelet does mount the volume after reboot, it's not able to match it with the Pod that needs it. Kubelet reports , while the volume is mounted with ID in my case (= the provisional name, we use for it) and not (=). It is not reproducible with enabled. <details</details<detailsAWS + AWS EBS CSI driver, but it should not be relevant. </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig storage /priority important-soon This is reproducible when SELinuxMountReadWriteOncePod is disabled and NewVolumeManagerReconstruction enabled. They both got enabled by default as beta in 1.28. So someone has to explicitly disable SELinuxMountReadWriteOncePod to hit this bug.
https://k8s- /kind bug /sig cluster-lifecycle /milestone v1.10 /priority failing-test cc also cc should this even be in 1.10 blocking dashboard?
/priority critical-urgent (who owns this?)
(also https://k8s-)
Is this actually running now? /cc
It looks like it's failing to up the cluster, I don't remember what the previous status of this job was, I thought all kubeadm 1.10 jobs were running previously...
The reason this failed was the cross CI job was failing to push the images that are used by that job. /cc
/subscribe
the latest cross build for 1.9 is as following We seem to have only one job that does cross builds on master : https://k8s-*build&i=nope&files=&repos=test-infra So the job fails ( for example in )
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When trying to list object using field spec.ServiceAccountName, we are getting the below error message. field label not supported: spec.serviceAccountName What you expected to happen: To be able to fetch pods using the list and watch based on the field 'spec.serviceAccountName' How to reproduce it (as minimally and precisely as possible): in minikube run Anything else we need to know?: Description: Unable to fetch pods based on the field 'spec.serviceAccountName'. When trying to get an overview of RBAC privileges in a cluster it is hard to find the objects attached to service accounts Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T20:17:28Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-06-27T20:08:34Z", GoVersion:"go1.10.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: minikube version: v0.28.0 OS (e.g. from /etc/os-release): NAME=Buildroot VERSION=2018.05 ID=buildroot VERSIONID=2018.05 PRETTYNAME="Buildroot 2018.05" Kernel (e.g. ): Linux minikube 4.16.14 SMP Mon Jun 11 16:20:15 UTC 2018 x86_64 GNU/Linux Install tools: kubeadm Others:
/sig architecture
You might do it by jsonpath filter
I intend to utilize it in the client-go list as an option
Not all fields are supported for field selector. There is a doc about field selector which is still under review: As far as I can see, supported field selectors for pods are listed here:
Didn't find that you have a pull request for it. :) Good luck!
Must be a result of When running kubelet in standalone mode got this panic: No panic run kubelet in standalone mode No response master branch <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node /sig storage /priority critical-urgent
/assign
I saw this as well. It is another instance of nil client pointer access.
Here's the old reconstruction logic with standalone kubelet handling:
Reading scattered docs, "standalone mode" is a kubelet without and it won't ever get any connection to the API server, right? Is there an e2e ~test~ job that runs kubelet in standalone mode?
Fix: I haven't found a presubmit job with a standalone kubelet.
I don't believe we have a presubmit for this (yet). I can repro this in local cluster with standalone kubelet with a small code change: I tried your diff and it works. Please feel free to try the above for double-verification.
I follow the instruction to start the kubernetes web UI. It's 404 when I open http://127.0.0.1:8080 . Finally I knew that the correct directory is http://127.0.0.1:8080/static/app/#/dashboard/ . We should start the web ui in root directory(I mean http://127.0.0.1:8080) so that anyone like me will not be confused.
/sub
I agree the UI isn't very discoverable. We should redirect from to the correct path. (Assuming that the UI is working well enough to expose it at all.)
I can do this if no one else is on it. Should we redirect and for all requests or just requests with specific user-agents or MIME types?
We return a list of resource paths on currently: We could either redirect for certain user-agents, or choose another, simpler, more obvious, top-level path, like or , which would at least show up in the list of valid paths.
That's great!
Great job :+1:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: PR introduced a new kubelet plugin registration mechanism. It is not flag gated. What you expected to happen: Since this feature is alpha, it should be flag gated and disabled by default (opt-in). How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: CC
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 3 days during code slush. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details