Octelium enables you to seamlessly provide identity-based, secret-less secure access to your AWS Lambda functions. Octelium provides you the following benefits:

• You no longer need to have allow unrestricted anonymous access to your AWS Lambda function URLs.
• Eliminate the need to manage AWS IAM identities and create, distribute, monitor and rotate AWS credentials for your, possibly hundreds or thousands of, human Users as well as workloads that actually need to access your Lambda functions. You can read more about Octelium secret-less access capabilities here.
• You can use Octelium's rich identity-based, context-aware, L7 aware, on a per-request basis, centralized access control via policy-as-code with CEL and OPA to enforce fine-grained access control way beyond of what AWS policies can offer (read more about Policies and access control here).
• Centralize identity management for all of your human Users via Octelium's OpenID Connect and SAML 2.0 IdentityProviders (read more here) as well as for your workload Users via OAuth2 client credentials (read more here) and bearer access tokens (read more here).

First you need to create a Lambda function and then create a function URL for it. You can do so by going to the Configuration tab of your lambda function and then go to the Function URL tab and then create one with an Auth type of "AWS_IAM" so that the Lambda function can be accessible to authorized AWS users. You can then create an IAM user and obtain an access key for that user with a lambda:InvokeFunction permission to that Lambda function (read more here). Now, you can create a secret for the secret access key as follows:

octeliumctl create secret lambda-1

Now we create the Service of our Lambda function as follows:

1
kind: Service
2
metadata:
3
  name: my-lambda
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  config:
8
    upstream:
9
      url: https://abcdef123456.lambda-url.eu-central-1.on.aws
10
    http:
11
      auth:
12
        sigv4:
13
          accessKeyID: ABCDEF...FEDCBA
14
          secretAccessKey:
15
            fromSecret: lambda-1
16
          region: eu-central-1
17
          service: lambda

Authorized Users can now invoke your Lambda function at the public URL https://my-lambda.<DOMAIN>. When it comes to access control, Octelium provides a rich layer-7 aware, identity-based, context-aware ABAC access control on a per-request basis where you can control access based on the HTTP request's path, method, body content, etc... using policy-as-code with CEL and Open Policy Agent (OPA) (You can read more in detail about Policies and access control here). Here is an example:

1
kind: Service
2
metadata:
3
  name: my-lambda
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  config:
8
    upstream:
9
      url: https://abcdef123456.lambda-url.eu-central-1.on.aws
10
    http:
11
      auth:
12
        sigv4:
13
          accessKeyID: ABCDEF...FEDCBA
14
          secretAccessKey:
15
            fromSecret: lambda-1
16
          region: eu-central-1
17
          service: lambda
18
  authorization:
19
    inlinePolicies:
20
      - spec:
21
          rules:
22
            - effect: ALLOW
23
              condition:
24
                all:
25
                  of:
26
                    - match: ctx.user.spec.email.endsWith("@example.com")
27
                    - match: ctx.user.spec.groups.hasAny(["dev", "ops"])
28
                    - match: ctx.request.http.path.startsWith("/prefix1")
29
                    - match: ctx.request.http.method in ["GET", "POST"]

If you have many Lambda functions that need to be protected, you can use Octelium's dynamic configuration (read more about dynamic configuration here) to protect multiple Lambda functions behind a single Service. For example, you might use different path prefixes for each Lambda function as follows:

1
kind: Service
2
metadata:
3
  name: my-lambda
4
spec:
5
  mode: HTTP
6
  isPublic: true
7
  dynamicConfig:
8
    configs:
9
      - name: function-1
10
        upstream:
11
          url: https://function-1.lambda-url.eu-central-1.on.aws
12
        http:
13
          path:
14
            removePrefix: /function-1
15
          auth:
16
            sigv4:
17
              accessKeyID: ABCDEF...FEDCBA
18
              secretAccessKey:
19
                fromSecret: lambda-1
20
              region: eu-central-1
21
              service: lambda
22
      - name: function-1
23
        upstream:
24
          url: https://function-2.lambda-url.eu-central-1.on.aws
25
        http:
26
          path:
27
            removePrefix: /function-2
28
          auth:
29
            sigv4:
30
              accessKeyID: ABCDEF...FEDCBA
31
              secretAccessKey:
32
                fromSecret: lambda-1
33
              region: eu-central-1
34
              service: lambda
35
    rules:
36
      - condition:
37
          match: ctx.request.http.path.startsWith("/function-1")
38
        configName: function-1
39
      - condition:
40
          match: ctx.request.http.path.startsWith("/function-2")
41
        configName: function-2

Now the https://function-1.lambda-url.eu-central-1.on.aws function can be accessed at https://my-lambda.<DOMAIN>/function-1 and the https://function-2.lambda-url.eu-central-1.on.aws function can be accessed at https://my-lambda.<DOMAIN>/function-2.

Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP here). You can read more about visibility here.

This was a very short guide to show you how to use Octelium to deploy, scale, route and provide dynamic zero trust secure access to your workloads. Here are a few more related features that you might be interested in:

• Routing not just by request paths, but also by header keys and values, request body content including JSON (read more here).
• Request/response header manipulation (read more here).
• Cross-Origin Resource Sharing (CORS) (read more here).
• gRPC mode (read more here).
• Secret-less access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more here).
• Exposing the API publicly for anonymous access (read more here).
• Application layer-aware ABAC access control via policy-as-code using CEL and Open Policy Agent (read more here).
• OpenTelemetry-ready, application-layer L7 aware auditing and visibility (read more here).