mirror of https://github.com/openkruise/kruise.git
fix typo and remove incident-response (#1584)
Signed-off-by: 守辰 <shouchen.zz@alibaba-inc.com>
This commit is contained in:
parent
2753c3a4dd
commit
f244b7ab34
|
|
@ -36,7 +36,7 @@ One of the most common-used features of it is to pull images from private reposi
|
|||
|
||||
## Proposal
|
||||
**Main idea**: In this design, we separate the logic of `Secret` and `SidecarSet`.
|
||||
In `SidecarSet` part, we only consider injecting their `imagePullSecrets` feilds into Pod.
|
||||
In `SidecarSet` part, we only consider injecting their `imagePullSecrets` fields into Pod.
|
||||
Users should manually distribute the required `Secrets` to all the namespaces that the `SidecarSet` may be instantiated.
|
||||
|
||||
### API Definition
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ the number of creating ephemeralcontainer will not exceed replicas.
|
|||
|
||||
the value of parallelism cannot exceed 10.
|
||||
|
||||
1. templete describe ephemeralcontainers spec.
|
||||
1. template describe ephemeralcontainers spec.
|
||||
|
||||
1. ttlSecondsAfterCreated means the TTL duration after ephemeral job has created.
|
||||
|
||||
|
|
@ -133,7 +133,7 @@ status:
|
|||
|
||||
The status.phase can be:
|
||||
|
||||
- Waitting: this EJOB waits ephemeral containers to be created.
|
||||
- Waiting: this EJOB waits ephemeral containers to be created.
|
||||
|
||||
it means no ephemeral container reach to running state.
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ already failed to complete it's task.
|
|||
- Error: some errors exits during ephemeralcontaienr creating.
|
||||
|
||||
status.failed means the number of failed completed ephemeralcontainers.
|
||||
status.success means the number of success compeleted ephemeralcontainers.
|
||||
status.success means the number of success completed ephemeralcontainers.
|
||||
status.waiting means the number of waiting ephemeralcontainers.
|
||||
status.running means the number of running ephemeralcontainers.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,89 +0,0 @@
|
|||
# Incident response
|
||||
|
||||
This serves to define how potential security issues should be triaged, how
|
||||
confirmation occurs, providing the notification, and issuing a security advisory
|
||||
as well as patch/release.
|
||||
|
||||
## Triage
|
||||
|
||||
### Identify the problem
|
||||
|
||||
Triaging problems allows maintainers to focus resources on the most critically
|
||||
impacting problems. Potential security problems should be evaluated against the
|
||||
following information:
|
||||
|
||||
* Which component(s) of the project is impacted?
|
||||
* What kind of problem is this?
|
||||
* privilege escalation
|
||||
* credential access
|
||||
* code execution
|
||||
* exfiltration
|
||||
* lateral movement
|
||||
* <!-- TODO: $CONTEXT_SPECIFIC_ISSUE -->
|
||||
* How complex is the problem?
|
||||
* Is user interaction required?
|
||||
* What privileges are required for this problem to occur?
|
||||
* admin
|
||||
* general
|
||||
* <!-- TODO: $CONTEXT_SPECIFIC_PRIVILEGE -->
|
||||
* What is the potential impact or consequence of the problem?
|
||||
* Does an exploit exist?
|
||||
|
||||
Any potential problem that has an exploit, permits privilege escalation, is
|
||||
simple, and does not require user interaction should be evaluated immediately.
|
||||
[CVSS Version 3.1](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator) can be
|
||||
a helpful tool in evaluating the criticality of reported problems.
|
||||
|
||||
### Acknowledge receipt of the problem
|
||||
|
||||
Respond to the reporter and notify them you have received the problem and have
|
||||
begun reviewing it. Remind them of the embargo policy, and provide them
|
||||
information on who to contact/follow-up with if they have questions. Estimate a
|
||||
time frame that they can expect to receive an update on the problem. Create a
|
||||
calendar reminder to contact them again by that date to provide an update.
|
||||
|
||||
### Replicate the problem
|
||||
|
||||
Follow the instructions relayed in the problem. If the instructions are
|
||||
insufficient, contact the reporter and ask for more information.
|
||||
|
||||
If the problem cannot be replicated, re-engage the reporter, let them know it
|
||||
cannot be replicated, and work with them to find a remediation.
|
||||
|
||||
If the problem can be replicated, re-evaluate the criticality of the problem, and
|
||||
begin working on a remediation. Begin a draft security advisory.
|
||||
|
||||
Notify the reporter you were able to replicate the problem and have begun working
|
||||
on a fix. Remind them of the embargo policy. If necessary, notify them of an
|
||||
extension (only for very complex problems where remediation cannot be issued
|
||||
within the project's specified window).
|
||||
|
||||
#### Request a CVE number
|
||||
|
||||
If a CVE has already been provided, be sure to include it on the advisory. If
|
||||
one has not yet been created, [GitHub functions as a CVE Numbering Authority](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories#cve-identification-numbers)
|
||||
and allows you to request one as part of the security advisory process. Provide
|
||||
all required information and as much optional information as we can. The CVE
|
||||
number is shown as reserved with no further details until notified it has been
|
||||
published.
|
||||
|
||||
## Notification
|
||||
|
||||
Once the problem has been replicated and a remediation is in place, notify
|
||||
subscribed parties with a security bulletin and the expected publishing date.
|
||||
|
||||
## Publish and release
|
||||
|
||||
Once a CVE number has been assigned, publish and release the updated
|
||||
version/patch. Be sure to notify the CVE group when published so the CVE details
|
||||
are searchable. Be sure to give credit to the reporter by *[editing the security
|
||||
advisory](https://docs.github.com/en/github/managing-security-vulnerabilities/editing-a-security-advisory#about-credits-for-security-advisories)*
|
||||
as they took the time to notify and work with you on the problem!
|
||||
|
||||
### Issue a security advisory
|
||||
|
||||
Follow the instructions from [GitHub to publish the security advisory previously
|
||||
drafted](https://docs.github.com/en/github/managing-security-vulnerabilities/publishing-a-security-advisory).
|
||||
|
||||
For more information on security advisories, please refer to the [GitHub
|
||||
Article](https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories).
|
||||
|
|
@ -500,7 +500,7 @@ func TestStatefulPodControlDeleteFailure(t *testing.T) {
|
|||
}
|
||||
}
|
||||
|
||||
func TestStatefulPodControlClaimsMatchDeletionPolcy(t *testing.T) {
|
||||
func TestStatefulPodControlClaimsMatchDeletionPolicy(t *testing.T) {
|
||||
// The claimOwnerMatchesSetAndPod is tested exhaustively in stateful_set_utils_test; this
|
||||
// test is for the wiring to the method tested there.
|
||||
fakeClient := &fake.Clientset{}
|
||||
|
|
|
|||
|
|
@ -617,7 +617,7 @@ func completeRollingUpdate(set *appsv1beta1.StatefulSet, status *appsv1beta1.Sta
|
|||
}
|
||||
}
|
||||
|
||||
// SortPodsAscendingOrdinal sorts the given Pods according to their oridinals.
|
||||
// SortPodsAscendingOrdinal sorts the given Pods according to their ordinals.
|
||||
func SortPodsAscendingOrdinal(pods []*v1.Pod) {
|
||||
sort.Sort(ascendingOrdinal(pods))
|
||||
}
|
||||
|
|
|
|||
|
|
@ -315,13 +315,13 @@ func TestRescheduleSubset(t *testing.T) {
|
|||
ec := GetWorkloadSpreadSubsetCondition(&exceptStatus.SubsetStatuses[i], appsv1alpha1.SubsetSchedulable)
|
||||
|
||||
if lc == nil && ec != nil {
|
||||
t.Fatalf("rescheudle failed")
|
||||
t.Fatalf("reschedule failed")
|
||||
}
|
||||
if lc != nil && ec == nil {
|
||||
t.Fatalf("rescheudle failed")
|
||||
t.Fatalf("reschedule failed")
|
||||
}
|
||||
if lc != nil && ec != nil && lc.Status != ec.Status {
|
||||
t.Fatalf("rescheudle failed")
|
||||
t.Fatalf("reschedule failed")
|
||||
}
|
||||
}
|
||||
})
|
||||
|
|
|
|||
|
|
@ -70,7 +70,7 @@ func TestHasOwnerRef(t *testing.T) {
|
|||
}
|
||||
}
|
||||
|
||||
func TestRemoveOnwer(t *testing.T) {
|
||||
func TestRemoveOwner(t *testing.T) {
|
||||
pvc := &v1.PersistentVolumeClaim{
|
||||
ObjectMeta: metav1.ObjectMeta{
|
||||
Namespace: "default",
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ func (h *PodCreateHandler) containerLaunchPriorityInitialization(_ context.Conte
|
|||
return false, nil
|
||||
}
|
||||
|
||||
// the return []int is prioirty for each container in the pod, ordered as container
|
||||
// the return []int is priority for each container in the pod, ordered as container
|
||||
// order list in pod spec.
|
||||
// the priorityFlag indicates whether this pod needs to launch containers with priority.
|
||||
// return error is there is any (e.g. priority value less than minimum possible int value)
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ func (h *ResourceDistributionCreateUpdateHandler) validateResourceDistributionSp
|
|||
}
|
||||
}
|
||||
if len(conflicted) != 0 {
|
||||
allErrs = append(allErrs, field.Invalid(fldPath, targets, fmt.Sprintf("ambiguous targets because namespace %v is in both IncludedNamespaces.List and ExcludedNamesapces.List", conflicted)))
|
||||
allErrs = append(allErrs, field.Invalid(fldPath, targets, fmt.Sprintf("ambiguous targets because namespace %v is in both IncludedNamespaces.List and ExcludedNamespaces.List", conflicted)))
|
||||
}
|
||||
|
||||
// 2. validate targets.NamespaceLabelSelector
|
||||
|
|
|
|||
|
|
@ -3,5 +3,12 @@ Ded = "Ded"
|
|||
ons = "ons"
|
||||
ist = "ist"
|
||||
WITHO = "WITHO"
|
||||
|
||||
[default]
|
||||
extend-ignore-re = [
|
||||
# *sigh* this just isn't worth the cost of fixing
|
||||
"sha256:.*",
|
||||
]
|
||||
|
||||
[files]
|
||||
extend-exclude = ["vendor/", "go.mod", "CHANGELOG.md"]
|
||||
|
|
|
|||
Loading…
Reference in New Issue