# Secure Access to AWS Lambda Functions > Octelium documentation. Canonical page: . Octelium enables you to seamlessly provide identity-based, secretless secure access to your [AWS Lambda](https://aws.amazon.com/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 secretless access capabilities [here](https://octelium.com/docs/octelium/latest/management/core/service/secretless.md). - 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](https://octelium.com/docs/octelium/latest/management/core/policy.md)). - Centralize identity management for all of your human *Users* via Octelium's OpenID Connect and SAML 2.0 *IdentityProviders* (read more [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md)) as well as for your workload *Users* via OAuth2 client credentials (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#oauth2-client-credentials)) and bearer access tokens (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#access-tokens)). 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](https://docs.aws.amazon.com/lambda/latest/dg/urls-invocation.html)). Now, you can create a *secret* for the secret access key as follows: ```bash octeliumctl create secret lambda-1 ``` Now we create the *Service* of our Lambda function as follows: ```yaml kind: Service metadata: name: my-lambda spec: mode: HTTP isPublic: true config: upstream: url: https://abcdef123456.lambda-url.eu-central-1.on.aws http: auth: sigv4: accessKeyID: ABCDEF...FEDCBA secretAccessKey: fromSecret: lambda-1 region: eu-central-1 service: lambda ``` > **Note:** > > Note that you have to set the `service` field to `lambda` and the `region` field to your actual region. Authorized *Users* can now invoke your Lambda function at the public URL `https://my-lambda.`. 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](https://octelium.com/docs/octelium/latest/management/core/policy.md)). Here is an example: ```yaml kind: Service metadata: name: my-lambda spec: mode: HTTP isPublic: true config: upstream: url: https://abcdef123456.lambda-url.eu-central-1.on.aws http: auth: sigv4: accessKeyID: ABCDEF...FEDCBA secretAccessKey: fromSecret: lambda-1 region: eu-central-1 service: lambda authorization: inlinePolicies: - spec: rules: - effect: ALLOW condition: all: of: - match: ctx.user.spec.email.endsWith("@example.com") - match: ctx.user.spec.groups.hasAny(["dev", "ops"]) - match: ctx.request.http.path.startsWith("/prefix1") - 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](https://octelium.com/docs/octelium/latest/management/core/service/dynamic-config.md)) to protect multiple Lambda functions behind a single *Service*. For example, you might use different path prefixes for each Lambda function as follows: ```yaml kind: Service metadata: name: my-lambda spec: mode: HTTP isPublic: true dynamicConfig: configs: - name: function-1 upstream: url: https://function-1.lambda-url.eu-central-1.on.aws http: path: removePrefix: /function-1 auth: sigv4: accessKeyID: ABCDEF...FEDCBA secretAccessKey: fromSecret: lambda-1 region: eu-central-1 service: lambda - name: function-1 upstream: url: https://function-2.lambda-url.eu-central-1.on.aws http: path: removePrefix: /function-2 auth: sigv4: accessKeyID: ABCDEF...FEDCBA secretAccessKey: fromSecret: lambda-1 region: eu-central-1 service: lambda rules: - condition: match: ctx.request.http.path.startsWith("/function-1") configName: function-1 - condition: match: ctx.request.http.path.startsWith("/function-2") configName: function-2 ``` Now the `https://function-1.lambda-url.eu-central-1.on.aws` function can be accessed at `https://my-lambda./function-1` and the `https://function-2.lambda-url.eu-central-1.on.aws` function can be accessed at `https://my-lambda./function-2`. > **Note:** > > If you have too many Lambda functions to be protected by Octelium, you might also have a look at *Namespaces* (read more [here](https://octelium.com/docs/octelium/latest/management/core/namespace.md)) to group your Lambda function *Services* according to your needs. Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#visibility)). You can read more about visibility [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md). 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](https://octelium.com/docs/octelium/latest/management/core/service/http.md#json-request-body)). - Request/response header manipulation (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#header-manipulation)). - Cross-Origin Resource Sharing (CORS) (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#cross-origin-resource-sharing-cors)). - gRPC mode (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#grpc)). - Secretless access to upstreams and injecting bearer, basic, or custom authentication header credentials (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#secretless-access)). - Exposing the API publicly for anonymous access (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/anonymous-access.md)). - Application layer-aware ABAC access control via policy-as-code using CEL and Open Policy Agent (read more [here](https://octelium.com/docs/octelium/latest/management/core/policy.md)). - OpenTelemetry-ready, application-layer L7 aware auditing and visibility (read more [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md)).