mirror of https://github.com/istio/istio.io.git
Expand the security vulnerability page. (#3195)
This commit is contained in:
Martin Taillefer
istio-bot
parent
149f9ddfbc
commit
2eebc0a3d5
|
|
@ -9,7 +9,9 @@ aliases:
|
|||
icon: bugs
|
||||
---
|
||||
|
||||
Oh no! You found a bug?
|
||||
Oh no! You found a bug? We'd love to hear about it.
|
||||
|
||||
## Product bugs
|
||||
|
||||
Search our [issue database](https://github.com/istio/istio/issues/) to see if
|
||||
we already know about your problem and learn about when we think we can fix
|
||||
|
|
@ -20,13 +22,12 @@ what's going on.
|
|||
If you think a bug is in fact a security vulnerability, please visit [Reporting Security Vulnerabilities](/about/security-vulnerabilities/)
|
||||
to learn what to do.
|
||||
|
||||
If you're running on Kubernetes, consider including a [cluster state
|
||||
archive](#generating-a-cluster-state-archive) in your bug report.
|
||||
|
||||
## Generating a cluster state archive
|
||||
### Kubernetes cluster state archives
|
||||
|
||||
If you're running on Kubernetes, consider including a cluster state
|
||||
archive with your bug report.
|
||||
For convenience, you can run a dump script to produce an archive containing
|
||||
all of the needed state from your Kubernetes cluster:
|
||||
all of the relevant state from your Kubernetes cluster:
|
||||
|
||||
* Run via `curl`:
|
||||
|
||||
|
|
@ -85,3 +86,11 @@ containing:
|
|||
{{< text bash >}}
|
||||
$ kubectl get $(kubectl get crd --no-headers | awk '{printf "%s,",$1}END{printf "attributemanifests.config.istio.io\n"}') --all-namespaces
|
||||
{{< /text >}}
|
||||
|
||||
## Documentation bugs
|
||||
|
||||
Search our [documentation issue database](https://github.com/istio/istio.io/issues/) to see if
|
||||
we already know about your problem and learn about when we think we can fix
|
||||
it. If you don't find your problem in the database, please navigate to the page
|
||||
with the problem, then select the gear menu at the
|
||||
top right of this page, and finally chose *Report a Site Bug*.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Reporting Security Vulnerabilities
|
||||
description: Responsible disclosure for Istio security vulnerabilities.
|
||||
title: Security Vulnerabilities
|
||||
description: How we handle security vulnerabilities.
|
||||
weight: 35
|
||||
icon: vulnerabilities
|
||||
---
|
||||
|
|
@ -8,13 +8,15 @@ icon: vulnerabilities
|
|||
We are very grateful to the security researchers and users that report
|
||||
back Istio security vulnerabilities. We investigate every report thoroughly.
|
||||
|
||||
## Reporting a vulnerability
|
||||
|
||||
To make a report, send an email to the private
|
||||
[`istio-security-vulnerabilities@googlegroups.com`](mailto:istio-security-vulnerabilities@googlegroups.com)
|
||||
mailing list with the vulnerability details. For normal product bugs
|
||||
unrelated to latent security vulnerabilities, please head to
|
||||
our [Reporting Bugs](/about/bugs/) page to learn what to do.
|
||||
|
||||
## When to report a security vulnerability?
|
||||
### When to report a security vulnerability?
|
||||
|
||||
Send us a report whenever you:
|
||||
|
||||
|
|
@ -23,7 +25,7 @@ Send us a report whenever you:
|
|||
- Think a vulnerability is present in another project that Istio
|
||||
depends on. For example, Envoy, Docker, or Kubernetes.
|
||||
|
||||
## When not to report a security vulnerability?
|
||||
### When not to report a security vulnerability?
|
||||
|
||||
Don't send a vulnerability report if:
|
||||
|
||||
|
|
@ -31,9 +33,9 @@ Don't send a vulnerability report if:
|
|||
- You need help applying security related updates.
|
||||
- Your issue is not security related.
|
||||
|
||||
## Security vulnerability response
|
||||
## Evaluation
|
||||
|
||||
The Istio security team acknowledges and analyzes each report within three
|
||||
The Istio security team acknowledges and analyzes each vulnerability report within three
|
||||
work days.
|
||||
|
||||
Any vulnerability information you share with the Istio security team stays
|
||||
|
|
@ -43,15 +45,38 @@ projects. We only share the information as needed to fix the issue.
|
|||
We keep the reporter updated as the status of the security issue moves
|
||||
from `triaged`, to `identified fix`, to `release planning`.
|
||||
|
||||
## Public disclosure timing
|
||||
## Fixing the issue
|
||||
|
||||
The Istio security team and the bug submitter negotiate a public
|
||||
disclosure date between them. We prefer to fully disclose the bug as
|
||||
soon as possible once a user mitigation is available.
|
||||
We consider reasonable to delay disclosure when the bug or the fix is
|
||||
not yet fully understood, the solution is not well-tested, or for
|
||||
vendor coordination. The time frame for disclosure is from immediate,
|
||||
especially if the bug is known publicly already, to a few weeks.
|
||||
As a basic default, we expect the report date and the disclosure date
|
||||
to be on the order of seven days apart. The Istio security team holds
|
||||
the final say on setting a disclosure date.
|
||||
Once a security vulnerability has been fully characterized, a fix is developed by the Istio team.
|
||||
The development and testing for the fix happens in a private GitHub repository in order to prevent
|
||||
premature disclosure of the vulnerability.
|
||||
|
||||
## Early disclosure
|
||||
|
||||
Before vulnerabilities are disclosed to the public, there is an early private disclosure to a small set of Istio partners.
|
||||
This is to enable partners that distribute Istio binaries to prepare to distribute the fix.
|
||||
|
||||
Early disclosure happens three working days prior to full public disclosure.
|
||||
|
||||
Please fill out the [Early Security Vulnerability Disclosure](https://github.com/istio/community/issues/new?template=early-disclosure-request.md) form to request being
|
||||
added to the early disclosure mailing list.
|
||||
|
||||
## Public disclosure
|
||||
|
||||
On the day chosen for public disclosure, a sequence of activities takes place as quickly as possible:
|
||||
|
||||
- Changes are merged from the private GitHub repository holding the fix into the appropriate set of public
|
||||
branches.
|
||||
|
||||
- Release engineers ensure all necessary binaries are promptly built and published.
|
||||
|
||||
- Once the binaries are available, an announcement is sent out on the following channels:
|
||||
|
||||
- The [Istio blog](/blog)
|
||||
- The [Announcements](https://discuss.istio.io/c/announcements) category on discuss.istio.io
|
||||
- The [Istio Twitter feed](https://twitter.cqom/IstioMesh)
|
||||
- The [#announcement channel on Slack](https://istio.slack.com/messages/CFXS256EQ/)
|
||||
|
||||
As much as possible this announcement should be actionable, and include any mitigating steps users can take prior to
|
||||
upgrading to a fixed version. The recommended target time for these announcements is 16:00 UTC from Monday to Thursday.
|
||||
This means the announcement will be seen morning Pacific, early evening Europe, and late evening Asia.
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ $ helm template install/kubernetes/helm/istio \
|
|||
--set pilot.sidecar=false > istio-minimal.yaml
|
||||
{{< /text >}}
|
||||
|
||||
然后**创建 istio-system namespace 并部署 Istio**：
|
||||
然后**创建 `istio-system` namespace 并部署 Istio**：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create namespace istio-system
|
||||
|
|
|
|||
Loading…
Reference in New Issue