-
Notifications
You must be signed in to change notification settings - Fork 687
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' of github.com:emissary-ingress/emissary into in…
…itial-metadata Signed-off-by: Ryan Burn <[email protected]>
- Loading branch information
Showing
355 changed files
with
7,850 additions
and
288 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,144 @@ | ||
| name: pytest | ||
| on: | ||
| push: | ||
| branches: | ||
| - master | ||
| paths-ignore: | ||
| - 'releng/**' | ||
| - 'charts/**' | ||
| - 'manifests/**' | ||
| - 'k8s-config/**' | ||
| - 'docs/**' | ||
| - '*.md$' | ||
| pull_request: | ||
| paths-ignore: | ||
| - 'releng/**' | ||
| - 'charts/**' | ||
| - 'manifests/**' | ||
| - 'k8s-config/**' | ||
| - 'docs/**' | ||
| - '*.md$' | ||
|
|
||
| jobs: | ||
| execute-pytests: | ||
| runs-on: ubuntu-latest | ||
| strategy: | ||
| matrix: | ||
| # NOTES: | ||
| # legacy mode does not do fast reconfigure - never test state true, true | ||
| # on master/release branch (legacy + reconfigure testing) | ||
| # - legacy + no reconfigure (true, false) | ||
| # - no legacy + reconfigure (false, true) | ||
| # - no legacy + no reconfigure (false, false) | ||
| # other branches (no legacy testing) | ||
| # - no legacy + no reconfigure (false, true) | ||
| # - no legacy + reconfigure (false, false) | ||
| pytest-settings: | ||
| - {legacy-mode: true, fast-reconfigure: false} | ||
| - {legacy-mode: false, fast-reconfigure: true} | ||
| - {legacy-mode: false, fast-reconfigure: false} | ||
| test: [integration, unit] | ||
| isMasterOrRelease: | ||
| # is this close enough to release branch being /^rel\/v[0-9]+\.[0-9]+\.[0-9]+(-ea)?$/ ? | ||
| - ${{ contains(github.ref, 'master') || startsWith(github.ref, 'refs/heads/rel/v') }} | ||
| exclude: | ||
| - isMasterOrRelease: false # if we are not master/release then we exclude legacy mode | ||
| pytest-settings: {legacy-mode: true, fast-reconfigure: false} | ||
| name: pytest-${{ matrix.test }} (legacy-mode:${{ matrix.pytest-settings.legacy-mode }}, fast-reconfigure:${{ matrix.pytest-settings.fast-reconfigure }}) | ||
| steps: | ||
| - run: echo "PREFIX=pytest-${{ matrix.test }}-legacy-mode.${{ matrix.pytest-settings.legacy-mode }}-fast-reconfigure.${{ matrix.pytest-settings.fast-reconfigure }}" >> $GITHUB_ENV | ||
| name: Set Unique Test prefix ${{ env.PREFIX }} | ||
| - run: echo "USE_LOCAL_K3S_CLUSTER=1" >> $GITHUB_ENV | ||
| if: ${{ matrix.test != 'unit' }} | ||
| name: "Set USE_LOCAL_K3S_CLUSTER=1" | ||
| - run: | | ||
| sudo sysctl -w fs.file-max=1600000 | ||
| sudo sysctl -w fs.inotify.max_user_instances=4096 | ||
| name: "Configure system file and inotify maximums (1600000/4096)" | ||
| - uses: actions/checkout@v2 | ||
| with: | ||
| fetch-depth: 0 | ||
| - uses: actions/setup-python@v2 | ||
| with: | ||
| python-version: '^3.9.5' | ||
| name: "Install Python (^3.9.5)" | ||
| - run: python --version | ||
| name: "Check python installed" | ||
| - uses: BSFishy/pip-action@v1 | ||
| with: | ||
| packages: | | ||
| awscli | ||
| packaging | ||
| name: "Install Python requirements with pip" | ||
| - uses: azure/setup-kubectl@v1 | ||
| if: ${{ matrix.test != 'unit' }} | ||
| id: install | ||
| with: | ||
| version: 'v1.19.12' | ||
| name: "Install kubectl (v1.19.12)" # maybe not? | ||
| - name: "Install/Setup K3d/K3s" | ||
| if: ${{ matrix.test != 'unit' }} | ||
| uses: nolar/[email protected] | ||
| - name: "Docker Login" | ||
| if: ${{ matrix.test != 'unit' }} | ||
| uses: docker/login-action@v1 | ||
| with: | ||
| username: ${{ secrets.DOCKER_BUILD_USERNAME }} | ||
| password: ${{ secrets.DOCKER_BUILD_PASSWORD }} | ||
| - name: "Configure Kubernetes cluster and Docker registry" | ||
| if: ${{ matrix.test != 'unit' }} | ||
| run: | | ||
| ./.ci/cluster-claim | ||
| rm -f ~/.kube/config | ||
| cp ~/.kube/kubeception.yaml ~/.kube/config | ||
| if test -e ~/.kube/kubeception.yaml; then | ||
| echo 'DEV_KUBECONFIG=~/.kube/kubeception.yaml' >> $GITHUB_ENV | ||
| fi | ||
| - name: make pytest-${{ matrix.test }} (legacy-mode:${{ matrix.pytest-settings.legacy-mode }}, fast-reconfigure:${{ matrix.pytest-settings.fast-reconfigure }} ) | ||
| timeout-minutes: 30 | ||
| run: | | ||
| export DEV_KUBE_NO_PVC=yes | ||
| export KAT_REQ_LIMIT=900 | ||
| export AMBASSADOR_LEGACY_MODE=${{ matrix.pytest-settings.legacy-mode }} | ||
| export AMBASSADOR_FAST_RECONFIGURE=${{ matrix.pytest-settings.fast-reconfigure }} | ||
| export TEST_XML_DIR=/tmp/test-logs/xml/ | ||
| export DEV_KUBECONFIG=~/.kube/kubeception.yaml | ||
| export DEV_REGISTRY=${{ secrets.DEV_REGISTRY }} | ||
| mkdir -p ${TEST_XML_DIR} | ||
| make pytest-${{ matrix.test }} | ||
| # teardown | ||
| - run: | | ||
| ./.ci/cluster-unclaim | ||
| if: always() && ${{ matrix.test != 'unit' }} | ||
| name: "Teardown Kubernetes cluster" | ||
| # collect logs | ||
| - uses: ./.github/actions/collect-testing-logs | ||
| if: always() | ||
| name: "Collect testing logs" | ||
| # upload artifacts | ||
| - name: "Upload Test Logs (test-logs)" | ||
| uses: actions/upload-artifact@v2 | ||
| with: | ||
| name: ${{ env.PREFIX }}--test-logs | ||
| path: /tmp/test-logs | ||
| - name: "Upload Cov Logs (cov_html)" | ||
| uses: actions/upload-artifact@v2 | ||
| with: | ||
| name: ${{ env.PREFIX }}--cov_html | ||
| path: /tmp/cov_html | ||
| - name: "Upload Pod Logs (pod-logs)" | ||
| if: ${{ matrix.test != 'unit' }} | ||
| uses: actions/upload-artifact@v2 | ||
| with: | ||
| name: ${{ env.PREFIX }}--pod-logs | ||
| path: /tmp/pod-logs | ||
| - name: "Upload XML Logs (xml)" | ||
| uses: actions/upload-artifact@v2 | ||
| with: | ||
| name: ${{ env.PREFIX }}--xml | ||
| path: /tmp/test-logs/xml/ | ||
| - uses: ./.github/actions/git-dirty-check | ||
| if: always() | ||
| name: "Check git not dirty from testing" |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,165 @@ | ||
| # Security Release Process | ||
|
|
||
| Emissary-ingress is a large, growing community comprising maintainers, volunteers, and users. | ||
| The Emissary community has adopted this security disclosure and response policy to ensure we | ||
| responsibly handle critical issues. | ||
|
|
||
| This disclosure process draws heavily from that of the Envoy Proxy -- many thanks! | ||
|
|
||
| ## Emissary Security Team (EMST) | ||
|
|
||
| Security vulnerabilities should be handled quickly and sometimes privately. The primary goal of this | ||
| process is to reduce the total time users are vulnerable to publicly known exploits. | ||
|
|
||
| The Emissary Security Team (EMST) is responsible for organizing the entire response including internal | ||
| communication and external disclosure but will need help from relevant developers to successfully | ||
| run this process. | ||
|
|
||
| The initial Emissary Security Team will consist of all [maintainers](MAINTAINERS.md), with communications | ||
| initially handled via email to [[email protected]](mailto:[email protected]). In the future, | ||
| we may change the membership of the EMST, or the communication mechanism. | ||
|
|
||
| ## Private Disclosure Process | ||
|
|
||
| The Emissary community asks that all suspected vulnerabilities be privately and responsibly disclosed | ||
| via email to [[email protected]](mailto:[email protected]). | ||
|
|
||
| ## Public Disclosure Processes | ||
|
|
||
| If you know of a publicly disclosed security vulnerability please IMMEDIATELY email | ||
| [[email protected]](mailto:[email protected]) to inform the Emissary Security Team (EMST) | ||
| about the vulnerability so they may start the patch, release, and communication process. | ||
|
|
||
| If possible the EMST will ask the person making the public report if the issue can be handled via a | ||
| private disclosure process (for example if the full exploit details have not yet been published). If | ||
| the reporter denies the request for private disclosure, the EMST will move swiftly with the fix and | ||
| release process. In extreme cases GitHub can be asked to delete the issue but this generally isn't | ||
| necessary and is unlikely to make a public disclosure less damaging. | ||
|
|
||
| ## Patch, Release, and Public Communication | ||
|
|
||
| For each vulnerability a member of the Emissary Security Team (EMST) will volunteer to lead | ||
| coordination with the "Fix Team" and is responsible for sending disclosure emails to the rest of | ||
| the community. This lead will be referred to as the "Fix Lead." | ||
|
|
||
| The role of Fix Lead should rotate round-robin across the EMST. | ||
|
|
||
| Note that, at present, it is likely that the Fix Team and the EMST are identical (all maintainers). | ||
| The EMST may decide to bring in additional contributors for added expertise depending on the area | ||
| of the code that contains the vulnerability. | ||
|
|
||
| All of the timelines below are suggestions and assume a private disclosure. The Fix Lead drives the | ||
| schedule using their best judgment based on severity and development time. If the Fix Lead is | ||
| dealing with a public disclosure all timelines become ASAP (assuming the vulnerability has a CVSS | ||
| score >= 4; see below). If the fix relies on another upstream project's disclosure timeline, that | ||
| will adjust the process as well. We will work with the upstream project to fit their timeline and | ||
| best protect our users. | ||
|
|
||
| ### Released versions and the `master` branch | ||
|
|
||
| If the vulnerability affects a supported version (typically the _most recent_ minor release, e.g. | ||
| 1.13), then the full security release process described in this document will be activated. A | ||
| patch release will be created (e.g. 1.13.10) with the fix, and the fix will also be made on | ||
| `master`. | ||
|
|
||
| If a vulnerability affects only `master`, the fix will be incorporated into the next release. | ||
| Security vulnerabilities that warrant action per this process will be considered release | ||
| blockers. | ||
|
|
||
| If a security vulnerability affects only unsupported versions but not `master` or a supported | ||
| version, no new release will be created. The vulnerability will be described as a GitHub issue, | ||
| and a CVE will be filed if warranted by severity. | ||
|
|
||
| ### Confidentiality, integrity and availability | ||
|
|
||
| We consider vulnerabilities leading to the compromise of data confidentiality or integrity to be | ||
| our highest priority concerns. Availability, in particular in areas relating to DoS and resource | ||
| exhaustion, is also a serious security concern for Emissary operators, given Emissary's common | ||
| placement at the edge. | ||
|
|
||
| In general, we will fix well-known resource consumption issues (e.g. high CPU or memory usage) in | ||
| the open, using our normal process for bugfixes. We will activate the security process for | ||
| disclosures that appear to present a significantly higher risk profile than simple "usage", for | ||
| example: | ||
|
|
||
| * A "query of death", where a single client query can crash Emissary entirely. | ||
| * Highly asymmetric resource exhaustion attacks, where very little traffic can cause resource | ||
| exhaustion, e.g. that delivered by a single client. | ||
|
|
||
| Note that while we generally consider the installation mechanisms provided by the Emissary-ingress | ||
| project (our published Helm charts and manifests) "safe", there is no way to guarantee that the | ||
| published installation mechanisms will always work in any specific setting. Ultimately, Emissary | ||
| operators need to understand the impact of their own configurations, especially in larger | ||
| installations. | ||
|
|
||
| ### Fix Team Organization | ||
|
|
||
| These steps should be completed within the first 24 hours of disclosure. | ||
|
|
||
| - The Fix Lead will work quickly to identify relevant engineers from the affected projects and | ||
| packages and CC those engineers into the disclosure thread. These selected developers are the | ||
| Fix Team. | ||
| - Work toward the fix will take place in private "security repos". The Fix Lead is responsible | ||
| for arranging for the Fix Team to have access to the private security repos (cf GitHub's | ||
| documentation on [duplicating a repository](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/duplicating-a-repository).) | ||
|
|
||
| ### Fix Development Process | ||
|
|
||
| These steps should be completed within the 1-7 days of Disclosure. | ||
|
|
||
| - The Fix Lead and the Fix Team will create a | ||
| [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS | ||
| Calculator](https://www.first.org/cvss/calculator/3.0). The Fix Lead makes the final call on the | ||
| calculated CVSS; it is better to move quickly than to spend time making the CVSS perfect. | ||
| - The Fix Team will work per the usual [Emissary Development Process](DEVELOPING.md), including | ||
| fix branches, PRs, reviews, etc. | ||
| - The Fix Team will notify the Fix Lead that work on the fix branch is complete once the fix is | ||
| present in the relevant release branch(es) in the private security repo. | ||
|
|
||
| If the CVSS score is under 4.0 ([a low severity score](https://www.first.org/cvss/specification-document#i5)) | ||
| the Fix Team can decide to slow the release process down in the face of holidays, developer | ||
| bandwidth, etc. These decisions must be discussed on the secalert mailing list. | ||
|
|
||
| ### Fix Disclosure Process | ||
|
|
||
| With the fix development underway, the Fix Lead needs to come up with an overall communication plan | ||
| for the wider community. This Disclosure process should begin after the Fix Team has developed a fix | ||
| or mitigation so that a realistic timeline can be communicated to users. | ||
|
|
||
| **Disclosure of Forthcoming Fix to Users** (Completed within 1-7 days of Disclosure) | ||
|
|
||
| - The Fix Lead will announce in `#emissary` and `#general` on the [Emissary Slack](https://a8r.io/slack) | ||
| informing users that a security vulnerability has been disclosed and that a fix will be made | ||
| available at a specific date and time in the future via this list. This time is the Release Date. | ||
| - The Fix Lead will include any mitigating steps users can take until a fix is available. | ||
|
|
||
| The communication to users should be actionable. They should know when to block time to apply | ||
| patches, understand exact mitigation steps, etc. | ||
|
|
||
| **Fix Release Day** (Completed within 1-21 days of Disclosure) | ||
|
|
||
| - The Fix Lead will PR the fix from the private security repo into [the Emissary repo](https://github.com/emissary-ingress/emissary). | ||
| - Maintainers will merge this PR as quickly as possible. Changes shouldn't be made to the commits even | ||
| for a typo in the CHANGELOG as this will change the git SHA of the commits leading to confusion and | ||
| potentially conflicts as the fix is cherry-picked around branches. | ||
| - The Fix Lead will request a CVE from [DWF](https://github.com/distributedweaknessfiling/DWF-Documentation) | ||
| and include the CVSS and release details. | ||
| - The Fix Lead will announce in `#emissary` and `#general` on the [Emissary Slack](https://a8r.io/slack) | ||
| stating the new releases, the CVE number, and the relevant merged PRs to get wide distribution and | ||
| user action. As much as possible this message should be actionable and include links on how to apply | ||
| the fix to user's environments; this can include links to external distributor documentation. | ||
| - The Fix Lead will remove the Fix Team from the private security repo. | ||
|
|
||
| ### Retrospective | ||
|
|
||
| These steps should be completed 1-3 days after the Release Date. The retrospective process | ||
| [should be blameless](https://landing.google.com/sre/book/chapters/postmortem-culture.html). | ||
|
|
||
| - The Fix Lead will send a retrospective of the process to [[email protected]](mailto:[email protected]) | ||
| and to `#emissary-dev` on the [Emissary Slack](https://a8r.io/slack), giving details on everyone | ||
| involved, the timeline of the process, links to PRs that introduced the issue (if relevant), | ||
| and any critiques of the response and release process. | ||
| - Maintainers and Fix Team are also encouraged to send their own feedback on the process to | ||
| [[email protected]](mailto:[email protected]), or to discuss it in `#emissary-dev` | ||
| on the [Emissary Slack](https://a8r.io/slack). Honest critique is the only way we will | ||
| improve as a community. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.