jiebi/CodeConvo huggingface dataset:
Code change:
} m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Related discussion:
text: CRI supports AppArmor, Seccomp and Sysctls via annotations , we should move them to typed and structured fields instead. (refer ) [x] Apparmor () [x] Sysctls () [x] Seccomp () cc
/cc
/sig node
Seccomp is addressed at .
Code change:
} m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Related discussion:
text: Seccomp profile is passed to runtime by in CRI: is relative to node's local seccomp profile root, it is defined in kubelet. But runtime doesn't know it. We should pass full profile path in CRI. cc/ Will file a PR to fix this later.
Add support for Seccomp sounds like a new feature. The milestone should be reset to , correct?
not really. The current implementation supports seccomp already. If it's missing critical information to function properly, this would be a bug.
are we blocking releases for CRI in 1.5? i was not sure, so marking this as non-release-blocker and leaving 1.5 milestone. please correct if i am mistaken.
I don't get why this is a 1.5 targetted thing myself. Yes we want CRI to be in a good state in 1.5, but afaik we have zero intention of anyone actually using (at the very least because of the lack of exec auth regressing kubelet security). why should this be part of 1.5?
First, this is a small enough change that allows non-docker integrations to properly support seccomp. Second, if "we have zero intention of anyone actually using" is a valid reason, we should never fix any bugs in CRI. We do want people to try using it (perhaps not in production yet). However, given that seccomp is only in alpha, I am ok with dropping this and just continue the docker support for now.
Perhaps I misunderstood the meaning of code freeze, but I thought it was only bug-fixes regardless of size of change (or exceptions that have gone through some process) What I meant is we don't intend this to be used generally as part of the 1.5 release. Because of that, I don't think we should consider bugs in CRI bugs for the purpose of the 1.5 release freeze. My statement is just that we shouldn't violate code-freeze for this. We should totally fix this right after the 1.5 freeze window ends, and saying that I'm arguing we should never fix anything is disingenuous and taking it to an absurd extreme.
the only thing we don't seem to agree on is whether seccomp support was considered to be supported for CRI in 1.5.
Code change:
} m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Related discussion:
text: My interpretation is that we assumed seccomp would be supported until we found out that it wouldn't for other runtimes due to the lack of profile path. That's the only reason why I considered this a bug. Of course we could say that this is not really an important feature in CRI, so we can drop it, but we can be more clear on that.
If there's a bug in a feature no one uses, does fixing it make a sound? I think what we're not agreeing on is the role of CRI in 1.5. I understood it as something that is not generally usable. We can't recommend a customer use it, even as an experimental feature, due to security aspects (if nothing else). Correct me if I'm wrong. It's a developer integration point, and developers integrating with it are doing so with the kubernetes master branch, not with some release. Those reasons together result in my opinion that CRI is still not really a customer/release feature, and thus bugs or features related to it should not be exceptions to the freeze window, but rather should targeted at master as soon as the freeze lifts. If this were already post-freeze, would we be cherry-picking this over to 1.5?
This is not true. cri-o is depending on this fix for apparmor support.
is it depending on the 1.5 release branch directly, or on master?
I think it's better to make this in 1.5, so cri-o could work with first release with experimental CRI. It helps to encourage people to use CRI and find features misses or bugs.
Modifying the user-specified annotation is a little bit unsettling. I think adding a new annotation explicitly for the path would be better. Or, we should just add an explicit field for this. I spoke to and separately. I still think this is a bug fix, but we may want to be more careful about the fix. Given the time constraint, let's just list this as a known issue and work on it for 1.6.
OK, let's move this to next release and think carefully about seccomp feature besides this: kubelet may just pass the profile as string via CRI; may assume the profile locate in a file in a known format and pass path to the runtime; or maybe some other solutions.
Code change:
} m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Related discussion:
text: We need to clearly define it. define profile format clearly
Please document known issues for 1.5 in
(copied from ) And let's move here to discuss how to pass profiles to runtime. Related with .
This is issue is related with two level APIs: CRI, since we may also want to support profiles from ConfigMaps, I think we should pass full profile contents instead of path to runtime. issues is also related with seccomp api in kube-apiserver, it is based on annotations today. We should define seccomp profile format clearly (see ) and decide whether to add struct types to pod spec or just continue the annotations way. I think it's more clear to add specific struct types to pod spec.
Agreed - the path stuff is really a crutch (and implementation-specific) - I think is the answer here.
I don't disagree, but it's not strictly a requirement for supporting ConfigMaps (kubelet could create a file with the contents). An open question is whether to pass it as a raw string, or wait for and pass the structured data. The annotations way is deprecated (). I think the bigger question is where/how to put the data. E.g. structured data in the API, unstructured (string type) data in the API, reference to another object (e.g. ConfigMap). If the Kubelet needs to parse the spec, I think that's a good argument for a structured data type (either a standalone object or embedded in the pod API).
Yes, already opened to replace annotations with typed structs. I personally prefer a structured data type in both kubernetes API and CRI. WDYT?
A counter argument is that as the spec grows or new features are , we need to keep updating the Kubernetes API to maintain parity, or update the code in each CRI implementation to translate the Kubernetes spec. OTOH, if we use unstructured data we can use 3rd party libraries to parse out the data we need (assuming the spec evolves in a backwards compatible way).
What spec?
Whichever seccomp profile spec is being implemented by runtimes. E.g. if we decide to base the Kubernetes seccomp profile API off the OCI seccomp profile spec, and OCI adds some new features, at some point we'd probably want to add those features to Kubernetes.
Code change:
} m.ApparmorProfile = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex <ins> case 10: if wireType != 2 { return fmt.Errorf("proto: wrong wireType = %d for field SeccompProfilePath", wireType) } var stringLen uint64 for shift := uint(0); ; shift += 7 { if shift >= 64 { return ErrIntOverflowApi } if iNdEx >= l { return io.ErrUnexpectedEOF } b := dAtA[iNdEx] iNdEx++ stringLen |= (uint64(b) & 0x7F) << shift if b < 0x80 { break } } intStringLen := int(stringLen) if intStringLen < 0 { return ErrInvalidLengthApi } postIndex := iNdEx + intStringLen if postIndex > l { return io.ErrUnexpectedEOF } m.SeccompProfilePath = string(dAtA[iNdEx:postIndex]) iNdEx = postIndex </ins> default: iNdEx = preIndex skippy, err := skipApi(dAtA[iNdEx:])

Related discussion:
text: It also means that if different runtimes support different feature sets, we'll be stuck either tracking only the common features, or specifying features that may be ignored by the runtime. This may be a non-issue if the seccomp feature set rarely changes.
Well, yes, but that applies to everything in the CRI, and is one of the tradeoffs we ma[d|k]e by introducing this abstraction in the first place.
My $0.02: Moving the existing logic/information for seccomp into a first-class field for CRI (as in ) is productive because of the known problems with the annotation approach. My initial proposal for seccomp support included a resource similar to what has proposed in kubernetes/community and we were unable to come to an agreement on the issue refers to here: I do not necessarily expect that we will be able to come to an agreement about the seccomp resource in time for 1.7, so I think we should proceed with and do backward compatible CRI changes later if we need to inject the content of the seccomp profile instead of the path. I think we would deeply regret embedding API surface to describe seccomp profiles in the Pod API :)
Code change:
t.Fatalf("Unexpected error validating the service %s %v", svc.Name, err) } } <ins> type serviceMergePatch struct { Spec specMergePatch `json:"spec,omitempty"` } type specMergePatch struct { Type         v1.ServiceType `json:"type,omitempty"` ExternalName string         `json:"externalName,omitempty"` } // tests success when converting ClusterIP:Headless service to ExternalName func Test_ServiceChangeTypeHeadlessToExternalNameWithPatch(t *testing.T) { controlPlaneConfig := framework.NewIntegrationTestControlPlaneConfig() _, server, closeFn := framework.RunAnAPIServer(controlPlaneConfig) defer closeFn() config := restclient.Config{Host: server.URL} client, err := clientset.NewForConfig(&config) if err != nil { t.Fatalf("Error creating clientset: %v", err) } ns := framework.CreateTestingNamespace("test-service-allocate-node-ports", server, t) defer framework.DeleteTestingNamespace(ns, server, t) service := &v1.Service{ ObjectMeta: metav1.ObjectMeta{ Name: "test-123", }, Spec: v1.ServiceSpec{ Type:      v1.ServiceTypeClusterIP, ClusterIP: "None", Selector:  map[string]string{"foo": "bar"}, }, } service, err = client.CoreV1().Services(ns.Name).Create(context.TODO(), service, metav1.CreateOptions{}) if err != nil { t.Fatalf("Error creating test service: %v", err) } serviceMergePatch := serviceMergePatch{ Spec: specMergePatch{ Type:         v1.ServiceTypeExternalName, ExternalName: "foo.bar", }, } patchBytes, err := json.Marshal(&serviceMergePatch) if err != nil { t.Fatalf("failed to json.Marshal ports: %v", err) } _, err = client.CoreV1().Services(ns.Name).Patch(context.TODO(), service.Name, types.StrategicMergePatchType, patchBytes, metav1.PatchOptions{}) if err != nil { t.Fatalf("unexpected error patching service using strategic merge patch. %v", err) } } </ins>

Related discussion:
text: the former and we should be able to cherry pick it.
for another look.
Cherry picks made: 22 21 20
Code change:
admissionapi "k8s.io/pod-security-admission/api" "github.com/onsi/ginkgo/v2" <ins> "github.com/onsi/gomega" </ins> ) var storageVersionServerVersion = utilversion.MustParseSemantic("v1.13.99")

Related discussion:
text: [X] test approval issue : [X] test pr : 3 May 2023 [X] two weeks soak end date : 16 May 2023 [X] test promotion pr : [X] remove endpoint form file According to following two APIsnoop queries, there are still 12 APIResources endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 12 endpoints. The e2e logs for this test are listed below. This query shows the following apiresources endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 12 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/open For tracking the rest of the processes
/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
Code change:
// Default: "" // +optional TLSMinVersion string `json:"tlsMinVersion,omitempty"` <ins> // rotateCertificates enables client certificate rotation. The Kubelet will request a // new certificate from the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletClientCertificate feature // must be enabled. // Default: false // +optional RotateCertificates bool `json:"rotateCertificates,omitempty"` </ins> // serverTLSBootstrap enables server certificate bootstrap. Instead of self // signing a serving certificate, the Kubelet will request a certificate from // the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletServerCertificate feature // must be enabled. // Default: false <ins> // +optional </ins> ServerTLSBootstrap bool `json:"serverTLSBootstrap,omitempty"` // authentication specifies how requests to the Kubelet's server are authenticated // Defaults:

Related discussion:
text: /kind cleanup What happened: and both require opt-in configuration knobs to the kubelet. They are kinda global settings, you probably either opt into dynamic cert rotation or you don't, so they qualify for being in the struct. The knob for enabling dynamic serving certs was (I fully support that :+1:). What you expected to happen: I'd like the same to happen to  to be consistent. (Also, we're planning to use the config file for the kubelet by default in kubeadm soon, and it'd be nice to be able to set this value then in a structured manner) /assign
Code change:
// Default: "" // +optional TLSMinVersion string `json:"tlsMinVersion,omitempty"` <ins> // rotateCertificates enables client certificate rotation. The Kubelet will request a // new certificate from the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletClientCertificate feature // must be enabled. // Default: false // +optional RotateCertificates bool `json:"rotateCertificates,omitempty"` </ins> // serverTLSBootstrap enables server certificate bootstrap. Instead of self // signing a serving certificate, the Kubelet will request a certificate from // the certificates.k8s.io API. This requires an approver to approve the // certificate signing requests. The RotateKubeletServerCertificate feature // must be enabled. // Default: false <ins> // +optional </ins> ServerTLSBootstrap bool `json:"serverTLSBootstrap,omitempty"` // authentication specifies how requests to the Kubelet's server are authenticated // Defaults:

Related discussion:
text: Flag name: Help text: <Warning: Beta featureAuto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. This is part of migrating the Kubelet command-line to a Kubernetes-style API. The flag should either be migrated to the Kubelet's API group, or simply removed from the Kubelet. If this could be considered an instance-specific flag, or a descriptor of local topology managed by the Kubelet, see: If this flag is only registered in os-specific builds, see: /assign /sig node /kind feature /priority important-soon /milestone v1.11 /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. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
"fmt" "k8s.io/api/core/v1" "k8s.io/klog/v2" <ins> "k8s.io/kubernetes/pkg/kubelet/util/format" </ins> "k8s.io/kubernetes/pkg/securitycontext" )

Related discussion:
text: when deploying a container that has runAsNonRoot but runs as root this error appears, but for pods with lots of containers it can be confusing which container failed, especially if there are 3-rd party webhooks that inject containers please add the container name to the message, making it
/sig api-machinery
/assign I can try this fix
I just submitted a pr, can you review it for me, is it as you expected?
thx, looks good!
/remove-sig api-machiner /sig node /area kubelet
Those labels are not set on the issue: <detailsIn response to : /remove-sig api-machiner /sig node /area kubelet 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
/remove-sig api-machinery
Code change:
// it does not have to be reimplemented. type counterRaiser struct { counter *metrics.Counter <del> reason  string </del> <ins> // programmatic id used in log and audit annotations prefixes id string // human readable explanation reason string </ins> } func (c *counterRaiser) IncreaseMetricsCounter(req *http.Request) { if req != nil && req.URL != nil { if hostname := req.URL.Hostname(); len(hostname) > 0 { <del> klog.Infof("invalid certificate detected while connecting to %q: %s", req.URL.Hostname(), c.reason) </del> <ins> prefix := fmt.Sprintf("%s.invalid-cert.kubernetes.io", c.id) klog.Infof("%s: invalid certificate detected connecting to %q: %s", prefix, hostname, c.reason) audit.AddAuditAnnotation(req.Context(), prefix+"/"+hostname, c.reason) </ins> } } c.counter.Inc()

Related discussion:
text: adds the metrics. the release note on that issue describes the go change, links to go docs, describes use of the option, the new metrics, and the kube-apiserver logs what would you expect kubeadm to do with this? GODEBUG off by default and let users override GODEBUG on their own (is this possible)? GODEBUG by default on all clusters? GODEBUG by default only on upgrade? The risk of 1 is that a user upgrades without reading release notes and breaks a cluster that has SHA-1 certs in webhooks, etc The risk of 2 is that we propagate accepting insecure certificates longer, even in new clusters that we know don't have any pre-existing bad certs The risk of 3 is that it makes an upgraded 1.23 → 1.24 cluster and a new 1.24 cluster inconsistent
the majority of kubeadm users use kubeadm managed CA and certificates. there are less users that use external CA to sign their own certificates. sha1 attacks surfaced more than a before kubeadm's creation and Git hash collusion made the problem more known around 2017 - that was at a time when kubeadm did not support external CA. given these facts, an estimate on my side is that there are currently no kubeadm users that use sha1 certificates, but i would not exclude the possibility entirely. if such users exists, they are on they own and my vote goes for option 1, until they migrate their PKI to something secure. if the same users log tickets for us, our response would be "please use GODEBUG and migrate ASAP". all users should be able to see the notes in IMO, the PR needs an "action required" to appear on top of the release notes.
that's helpful, thanks agreed. weird, I set , but the label didn't get . the label manually.
and there's a way for them to set that envvar in kube-apiserver manifests when using kubeadm?
There's been a lot of intermittent github webhook delivery issues in the past few weeks or so, slash commands are going to be somewhat unreliable :/
they could use kubeadm patches to override the YAML manifest defaults - i.e. the contents of v1.Container -Env:
Code change:
break } } <del> if found == false { </del> <ins> if !found { </ins> return false } } for _, leftPair := range newPermission.UserIdGroupPairs { <ins> found := false </ins> for _, rightPair := range existing.UserIdGroupPairs { if isEqualUserGroupPair(leftPair, rightPair, compareGroupUserIDs) { <del> return true </del> <ins> found = true break </ins> } } <del> return false </del> <ins> if !found { return false } </ins> } return true

Related discussion:
text: Per : the surrounding loop is unconditionally terminated (SA4004) It does look very suspicious.
Pertinent patches: AWS: Set up security groups, to mirror GCE firewalling Fix AWS ip permission comparison on security group
This needs to be triaged as a release-blocker or not for 1.5
all issues must be labeled either release blocker or non release blocking by end of day 18 November 2016 PST. (or please move it to 1.6) cc
Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.
This was a bug where we had multiple userid/group pairs, but we only ever called it with 0 or 1 elements. Fix in but kicking out of the 1.7 milestone.