istio-ecosystem / readme Goto Github PK

As we agreed in the Network Working Group Meeting, we need to create a new repo to accommodate the consul mcp adapter.

Meeting note https://docs.google.com/document/d/1xHy2jQ8oiwMponMVY2zJr2eUAmHW_Hi9JK42a7cg5Pc/edit

@linsun @sdake
Can you please help to update to allow 3rd party ORBs for istio-ecosystem projects:
https://app.circleci.com/settings/organization/github/istio-ecosystem/security

Q: Name of the repo
A：hsm-sds-server

Q: Description of the repo
A: This repo follows the SDS extension standard of Envoy and implements an external SDS server via more secure solution which is known as Hardware Security Module(HSM). By using this repo,

1. User can maintain the credentials for workloads managed by Istio/Envoy in more secure scenario via external SDS server
2. Besides supporting management for new credentials, it also allows user to upload existing credentials and manages them in higher security level
3. This external SDS server can be used for both gateways and workload sidecars to provide their credential information

Q: How is the repo related to the Istio project?
A: There are at least 3 proposals of Istio community related to this repo as below:
The Secret Discovery Service provided by istiod can be used to obtain the credentials from Kubernetes secrets for user's workloads in Istio.
However, referencing credentials from other sources instead Kubernetes Secrets is a meaningful requirement for Istio users, for example, Istio user may want to maintain the workload's credentials by themselves, it means that Istio sidecar can fetch the credentials from alternative backends which can be an external SDS/HTTP backends in safety mode. Below are some related proposals in Istio community:

1. Istio Envoy mTLS Private Key Protection with HSM
2. Extending credentialName storage backends
3. External SDS server Support for gateways
4. Auth for Istiod SDS
5. Protect the private keys in Envoy with Intel SGX

Q: What are the GitHub ids of the initial admins of the repo?
A: There are 3 initial admins: Chen-Xintong, irisdingbj and zhlsunshine

We (Red Hat) are working on a new approach for our Istio-based Service Mesh distribution, with a more close-to-upstream approach, in contrast of having a fork with so many downstream changes. This effort is being tracked as "Service mesh 3.0" internally.

As part of this effort, we are rewriting our operator (formerly Maistra operator), intended to work with plain upstream Istio charts and also intended to work with vanilla Kubernetes, not only on OpenShift.

This operator is in heavy development right now, and is currently being tracked in this branch: https://github.com/maistra/istio-operator/tree/maistra-3.0

We also are working on a nightly build of it that shows up in the Operator Hub.

It already works right now, and it's able to deploy Istio from master.

Plus, we are willing to rename it so that it's closer to Istio (e.g, by removing maistra everywhere). We have not decided the new name yet. Our goal is that it eventually becomes the official Istio operator, so, when that happens, it could be called just Istio Operator.

@istio-ecosystem/readme team (members of the org)
Please add a one line description of your respective projects
The README will service as a directory that lists the projects and details regarding the project.

1. Name of the repo:
   Acmg

2. Description of the repo
   istio/istio#42360
   istio/istio.io#11888

3. How is the repo related to the Istio project?
   As a centralized installation mode of istio.

4. What are the GitHub ids of the initial admins of the repo?
   yuri-lcy

5. License of the repo?
   Apache Licence 2.0

thanks