Add EP-10573: Support for AWS Lambda #10644
Conversation
Signed-off-by: timflannagan <[email protected]>
design/10573.md
Outdated
|
|
||
| ### API Changes | ||
|
|
||
| #### Upstream |
There was a problem hiding this comment.
Pseudoblocked based on the outcome of the #10611 issue.
There was a problem hiding this comment.
just to confirm the plan is to keep upstream (or whatever it's named) as there is some details - that need to be kept or reimplemented.
- header manipulations (confirmed that is currently used by customers) https://docs.solo.io/gateway/latest/traffic-management/destination-types/upstreams/lambda/get-started/#known-limitations
- also this is required if GG is set to integrate with Istio
Signed-off-by: timflannagan <[email protected]>
timflannagan
force-pushed
the
design/aws-lambda-proposal
branch
from
e500633 to
e1ec54c
Compare
design/10573.md
Outdated
| ) | ||
|
|
||
| // AwsUpstream is an upstream that configures AWS Lambda functionality. | ||
| type AwsUpstream struct { |
There was a problem hiding this comment.
One mistake I think we made the first go around with the AWS API, and that the upstream filter does a good job at, is separating the feature from the auth mechanism. There's a bit of language around here around a separation of Lambda and AWS Auth which I think is a good direction to move in. Perhaps AWS Auth on the upstream and Lambda on the route or something like that.
There was a problem hiding this comment.
it feels like aws connectivity is unlikely to be formalized as part of sig gateway apis so i like the idea of hewing closely to the envoy implementation for now and leaking some of that back in our api. Therefore it would be cool if we can say that the upstream will sign requests for aws or something.
https://github.com/envoyproxy/envoy/blob/cedb633dafc8fe69cb52098a8db2527126db9ee7/docs/root/configuration/http/http_filters/aws_request_signing_filter.rst#L2
design/10573.md
Outdated
| The AWS Lambda plugin will be implemented in the `internal/kgateway/extensions2/plugins/upstream` directory. At a high-level, the following changes will be made: | ||
|
|
||
| 1. Configure the lambda ARN in the [upstream HTTP filter](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/aws_lambda_filter#configuration-as-an-upstream-http-filter). |
There was a problem hiding this comment.
Is this an upstream_http_filter on the router or on the cluster?
Signed-off-by: timflannagan <[email protected]>
- Add mention that API needs to be foundational enough to support other AWS services - Add IRSA as a goal - Refactor proposal to embed function-level config in the Upstream API (vs. RoutePolicy API) - Clarify Istio auto-mtls testing requirement - Identify Localstack IAM pro limitations for IRSA integration - Separate auth and lambda configuration in the AWS Upstream Signed-off-by: timflannagan <[email protected]>
Signed-off-by: timflannagan <[email protected]>
Signed-off-by: timflannagan <[email protected]>
design/10573.md
Outdated
|
|
||
| ### Alternative 1: Adopt existing synthetic `Parameter` GVK | ||
|
|
||
| The previous approach for this feature relied on the synthetic `Parameter` GVK. This proposal moves away from this approach in favor of a more flexible and maintainable solution that can be extended to support other AWS services in the future. |
There was a problem hiding this comment.
Might be worth explicitly calling out that the Gloo Gateway synthetic Parameter approach limits us to a single config per "parameter", meaning it's not feasible to express all necessary pieces of the AWSLambdaConfig (at least without redesign)
|
Had another thought here, not sure if it's something we should discuss on the design doc or in the impl; Is there a difference between the Solo Lambda filter and the upstream AWS filter w.r.t. the amount of envoy clusters created? |
|
@lgadban I'd have to defer to others on that. AFAIK, the previous envoy-gloo implementation translate a portion on the cluster and processed the Parameters GVK on the per-route filter. That's fairly consistent with how the upstream lambda filter operates, so I think the implementation w.r.t # of clusters would be the same. Good idea on chalking this up on the implementation PR though -- I wanted to capture some of the high-level plugin changes since this proposal had implementation-specific concerns (e.g. envoy-gloo vs upstream envoy) that needed consensus for historical purposes, but nothing prevents us from updating the doc if there's any drift in the proposed implementation. |
Signed-off-by: timflannagan <[email protected]>
| - Not recommended for production use | ||
| - Suitable only for development and testing | ||
| 3. **Future Authentication Methods** (Optional): | ||
| - AWS STS token exchange |
There was a problem hiding this comment.
I might be mistaken, but was under the impression that AWS secret approach allows user to supply - Either AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY or AWS STS Token (which short lived)
Signed-off-by: timflannagan <[email protected]>
Description
Add an enhancement proposal for #10573.
Checklist: