Skip to content

Commit

Permalink
restrict access to priave images
Browse files Browse the repository at this point in the history
Signed-off-by: huabing zhao <zhaohuabing@gmail.com>
  • Loading branch information
zhaohuabing committed May 7, 2024
1 parent 4f2ad71 commit 59dbadd
Showing 1 changed file with 23 additions and 11 deletions.
34 changes: 23 additions & 11 deletions site/content/en/contributions/design/wasm-extension.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,31 +19,43 @@ Google Container Registry, and Amazon Elastic Container Registry, to Envoy proxi
Envoy lacks native OCI image support, therefore, EG needs to download Wasm modules from OIC registries,
cache them locally in the file system, and serve them to Envoy over HTTP.

**HTTP Code Source:** For HTTP code source, we have two options: serve Wasm modules directly from their
#### HTTP Code Source

For HTTP code source, we have two options: serve Wasm modules directly from their
original HTTP URLs, or cache them in EG (as with OCI images). Caching both the HTTP Wasm modules and OCI
images inside EG can make UI consistent, for example, sha256sum can be calculated on the EG side and made
optional in the API. This will also make the Envoy proxy side more efficient as it won’t have to download the
Wasm module from the original URL every time, which can be slow.

**Memory Optimization:** Since we cache Wasm modules in the file system, we can optimize the memory usage
#### Memory Optimization

Since we cache Wasm modules in the file system, we can optimize the memory usage
of the cache and the HTTP server to avoid introducing too much memory consumption by this feature.
For example, when receiving a Wasm pulling request form the Envoy, we can open the Wasm file and write
the file content directly to response, and then close the file. There won’t be significant caching involved.
However, we need to balance the memory usage and the efficiency, which could be addressed in implementation.

**Caching Mechanism:** Cached files will be evicted based on LRU(Last recently used)algorithm.
#### Caching Mechanism

Cached files will be evicted based on LRU(Last recently used)algorithm.
If the image’s tag is latest, then they will be updated periodically. The cache clean and update periods
will be configurable.

**Authn & Authz:**
* To prevent unauthorized proxies from accessing the Wasm modules, the communication between the Envoy and EG will be
#### Restrict Access to Private Images

* **Client Authn with MTLS:** To prevent unauthorized proxies from accessing the Wasm modules, the communication between the Envoy and EG will be
secured using mutual TLS.
* To prevent unauthorized access to the Wasm modules, the user who creates the EEP must have the appropriate permissions
to access the OCI registry. For example, if two users create EEPs in different namespaces (ns1, ns2) accessing the same
OCI image, each must also create a unique secret with registry credentials (secret1 for user1 in ns1, secret2 for user2 in ns2).
EG will validate the provided secret against the OCI registry before serving the Wasm module to the target HTTPRoute/Gateway of that EEP.
* To prevent unauthorized access to the Wasm modules, the download URL will be appended with a generated secret suffix
that can be validated by the EG.
* **User Authn with Registry Credentials:** To prevent unauthorized users from accessing the Wasm modules, the user who creates the EEP must have the appropriate
permissions to access the OCI registry. For example, if two users create EEPs in different namespaces (ns1, ns2) accessing
the same OCI image, each must also create a unique secret with registry credentials (secret1 for user1 in ns1, secret2
for user2 in ns2). EG will validate the provided secret against the OCI registry before serving the Wasm module to the
target HTTPRoute/Gateway of that EEP.
* **Unguessable Download URLs:** It's possible that users who have no permission to access a private OCI image could create
EEPs to bypass the EG permission check. For example, a user could create an EEP, inject a Wasm filter, and put the download
URL of a private OCI image in the Wasm filter configuration. To prevent this, we need to make the download URL unguessable.
The download URL will be generated by EG and will be a random string that is impossible to guess. If a user can get the
config dump the Envoy Proxy, they can still get the download URL. However, they won’t be able to do so without
the permission to access the config dump of Envoy Proxy, which is a more restricted permission (usually Admin role).

## Alternative Considered

Expand Down

0 comments on commit 59dbadd

Please sign in to comment.