DEV Community: Kurt Feeley

Find Source Code Vulnerabilities with CodeQL Before You Commit

Kurt Feeley — Tue, 08 Aug 2023 02:09:16 +0000

You have a plethora of Python code to commit for your new Django API. STOP! Before you commit and push, first scan your source code with the CodeQL CLI!

Photo by iMattSmart on Unsplash

The Solution

In this tutorial, we’ll go over scanning Python source code for vulnerabilities in a development environment using the CodeQL CLI.

Prerequisites

To complete this tutorial, you will need to install the CodeQL CLI.

Our Dev Environment

This tutorial was developed using Ubuntu 22.10, Python 3.10.6, CodeQL CLI 2.13.1 and Visual Studio Code 1.78.2. Some commands/constructs may vary across platforms.

What is CodeQL?

CodeQL is a type of static application security testing (SAST) scanner that scans source code for vulnerabilities. A vulnerability is a weakness in an application that allows an attacker to cause harm to the application’s owner, the application users, and/or organizations that rely on the application, et. al. Popular attacks include: SQL injection, cross-site scripting and brute force attacks. Using a tool like CodeQL early in the development process can save time, money and possibly prevent damage to a company’s reputation.

1) Setup the CodeQL CLI

Download the CodeQL CLI

Point your browser to the CodeQL releases page on GitHub and download the archive that corresponds to the platform that you are using. For this tutorial, we are downloading and using the release specified with “linux64” in the filename.

CodeQL Releases: https://github.com/github/codeql-cli-binaries/releases

Once the file has been downloaded, extract the files from the archive. For our Linux system, we’ll use the unzip command.

$ unzip codeql-linux64.zip -d ~/bin/codeql/

We are going to take one more step and add the codeql executable to our PATH variable so that we can call “codeql” from any location within the OS. On our Ubuntu system we can accomplish this by modifying the PATH variable in the ~/.profile file by appending the path of the codeql executable.

Test the CodeQL CLI

We can test the CodeQL CLI by checking the version at the command line.

$ codeql ––version

If everything is setup correctly, We should see output something like this:

CodeQL command-line toolchain release 2.13.1.
Copyright (C) 2019-2023 GitHub, Inc.
Unpacked in: /home/user/bin/codeql
Analysis results depend critically on separately distributed query and
extractor modules. To list modules that are visible to the toolchain,
use ‘codeql resolve qlpacks’ and ‘codeql resolve languages’.

You can further test by using the following command to get a list of the languages that can be used.

$ codeql resolve languages

Download the CodeQL Language Packs

To download precompiled queries for Python, use the following command:

$ codeql pack download codeql/python-queries

2) Create the CodeQL Database

Now that we have CodeQL downloaded and configured, we can create the CodeQL database.

Create a Directory for the CodeQL Database

The first thing we will need to do is create a directory to house the CodeQL database.

$ mkdir ~/codeql-dbs

Create the CodeQL Database

Now that we have a location for the database, let’s change to the directory of your app.

$ cd ~/source/python-app

Now we are set to create the CodeQL database with the following command:

Parameters:
~/codeql-dbs/python-app: The CodeQL database location.
language: The language to scan. In this case, Python.

$ codeql database create ~/codeql-dbs/python-app \
––language=python

If everything goes to plan, the output of the database create command will end with something like this:

“Successfully created database at /home/user/codeql-dbs/python-app.”

3) Scan the Source Code for Vulnerabilities

With the CodeQL database created, we can start to scan our source code.

Create a Directory for the CodeQL Output

CodeQL aggregates its findings in an output file. Let’s create a directory to house the output file.

$ mkdir ./codeql-output/

Code Analysis

Running the following command will instruct CodeQL to analyze the code using the previously built database for, “python-app.”

Parameters:
~/codeql-dbs/python-app: The CodeQL database location.
format: The output format. (Also supports SARIF and graph formats)
output: The path to the output file.

$ codeql database analyze ~/codeql-dbs/python-app \
––format=”csv” \
––output=”./codeql-output/scan.csv”

When CodeQL completes its analysis, the console should display a message like:

Shutting down query evaluator.
Interpreting results.
Analysis produced the following diagnostic data:
| Diagnostic | Summary |
+——————————+———–+
| Compilation message | 3 results |
| Successfully extracted files | 6 results |
Analysis produced the following metric data:
| Metric | Value |
+—————————————-+——–+
| Total lines of Python code in the database | 13,700 |

View the CodeQL Analysis Output

$ nano ./codeql-output/scan.csv

Summary

We have concluded this tutorial where you have learned how to scan Python source code for vulnerabilities in a development environment using the CodeQL CLI.

Now, before you commit code for that Django API –– scan it for source code vulnerabilities with CodeQL before you commit.

3 Things: Developing Amazon SQS Based Solutions

Kurt Feeley — Mon, 12 Sep 2022 13:31:22 +0000

Amazon Simple Queue Service or Amazon SQS is a distributed message queuing service that enables developers to build loosely coupled solutions. Often valued for its ease of use, Amazon SQS queues can be spun up in a matter of seconds from the AWS console, SDK or the CLI. Still, there are subtleties that developers should be aware of when developing solutions with Amazon SQS.

Photo by Shumilov Ludmila on Unsplash

Encryption

Messages stored in an Amazon SQS queue is data at rest. And, we can protect that data by encrypting it with KMS keys, just like we would if we were going to protect data in an Amazon S3 bucket or an Amazon SNS topic. With Amazon SQS Server-side encryption with KMS, messages are encrypted when they are received by SQS and are decrypted when delivered to a message consumer that is authorized for the SQS message queue and the KMS key.

Alternatively, Amazon Simple Queue Service provides it's own server-side encryption using SQS-managed encryption keys. Encrypting an SQS queue using SQS-managed encryption keys is as easy as using the following command:

$ aws sqs set-queue-attributes \
   ––queue-url https://(MyQueueURL) \
   ––attributes '{"SqsManagedSseEnabled": "true"}'

Temporal Messaging

By default, messages that are stored in Amazon SQS are designed for "At-Least-Once Delivery". That is, an Amazon SQS message will be delivered at least once, but can be delivered more than once and there is no guarantee that the messages will stay ordered. However, if you need messages delivered in order and only once, you may opt for Amazon SQS FIFO queues. Amazon SQS FIFO queues are designed for, Exactly-Once Processing, where messages are only delivered once and are delivered in the order of, First-In-First-Out.

Below is an example of sending a message to an Amazon SQS FIFO queue using the AWS .NET SDK. Note the use of the "MessageGroupId" property. This is a requirement for FIFO messaging.

SendMessageRequest sendMessageRequest = new SendMessageRequest(queueUrl, message);

sendMessageRequest.MessageGroupId = "message-group-1";

var sqsClient = new AmazonSQSClient();

await sqsClient.SendMessageAsync(sendMessageRequest);

Message Retention

Messages in Amazon SQS can not be stored forever. In fact, messages in Amazon SQS can be stored for a maximum of 14 days and for as little as 1 minute. By default, the Amazon SQS message retention period is a generous 4 days.

The following is an example of a command for setting an Amazon SQS queue to have a retention period of 1 minute using the AWS CLI.

$ aws sqs set-queue-attributes \
   ––queue-url https://(MyQueueURL) \
   ––attributes '{"MessageRetentionPeriod": "60'

Want to know more about the tech in this article? Checkout these resources:

AWS CLI, Configuring the AWS CLI, AWS .NET SDK, .NET

Securing .NET App Secrets with AWS Secrets Manager

Kurt Feeley — Thu, 02 Jun 2022 16:31:20 +0000

AWS Systems Manager Parameter Store is a great all around addition to your configuration and secrets management story. Parameter Store can be a cost effective solution as there isn't a charge for standard parameters. Parameter Store supports the storage of common configuration data like a URL (String Type) and data that's a bit more complex like a list of OAuth2 scopes (StringList Type) but, AWS Systems Manager Parameter Store also supports more sensitive configuration data like secrets, passwords and tokens (SecureString Type).

So, why use AWS Secrets Manager? AWS Secrets Manager features automated secret rotation and direct integration with services like RDS, Redshift, and DocumentDB. So, if you need to automatically rotate secrets or need integration with data storage technologies like RDS, Redshift, and DocumentDB, AWS Secrets Manager may be the right choice for you.

In this post we’ll focus on AWS Secrets Manager, but if AWS Systems Manager Parameter Store sounds more like your thing, check out this post on Using AWS Systems Manager Parameter Store as a .NET Configuration Provider.

Photo by saeed karimi on Unsplash

The Solution

In this article, we’ll take a look at using AWS Secrets Manager to store and retrieve confidential data. We’ll create a .NET API as the reference application and we'll use the AWS CLI and a .NET library developed by AWS that makes this process simple.

Prerequisites

To complete this solution, you will need the .NET CLI which is included in the .NET 6 SDK. In addition, you will need to download the AWS CLI and configure your environment for the AWS CLI. You will also need to create an AWS IAM user with programmatic access with the appropriate permissions to create and read secrets in AWS Secrets Manager.

Warning: some AWS services may have fees associated with them.

The Dev Environment

This tutorial was developed using Ubuntu 20.04, AWS CLI v2, .NET 6 SDK and Visual Studio Code 1.66.2. Some commands/constructs may very across systems.

Store Secrets with the AWS CLI

Using the AWS CLI, we’ll first create a random password.

$ aws secretsmanager get-random-password

The response will look something like the following:

{
   “RandomPassword”: “txRxQ6#[Muq_%oVVg,0vLrDJ;7{GG^Gy”
}

Let’s now store that password in AWS Secrets Manager. Take note of the name of the secret.

$ aws secretsmanager create-secret  \
    ––name test-secret \
    ––secret-string 'txRxQ6#[Muq_%oVVg,0vLrDJ;7{GG^Gy'

On completion, you will get a response with the ARN, Name and VersionId.

Create the .NET Test Application

With the secret created, let’s create a test application that integrates with AWS Secrets Manager which will allow us to retrieve the stored secret. For this example, we will use a .NET API.

$ dotnet new webapi ––name Api

Now that we have a reference application, let’s pull in the Nuget that contains the AWS Secrets Manager Caching library with the following command.

$ dotnet add Api/ package AWSSDK.SecretsManager.Caching

Let’s go into the Program.cs file within the new "Api" application and add a few lines directly below the builder variable declaration:

builder.Services.AddScoped<IAmazonSecretsManager>(a =>
      new AmazonSecretsManagerClient(RegionEndpoint.USEast1)
);

These lines will setup the dependency injection so that when a class requires an IAmazonSecretsManager based class, an AmazonSecretsManagerClient will be supplied.

The Program.cs file should now look like:

using Amazon;
using Amazon.SecretsManager;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddScoped<IAmazonSecretsManager>(a =>
      new AmazonSecretsManagerClient(RegionEndpoint.USEast1)
);

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

To demonstrate the use of Secrets Manager, let’s create a Controller named SecretController.cs. In the SecretController class, let's create a GetSecret method with the following logic.

This exercise is obviously for demonstration purposes only and not based on a true use case.

[HttpGet]
public async Task<IActionResult> GetSecret()
{
    GetSecretValueRequest request = new GetSecretValueRequest
    {
        SecretId = "test-secret",
        VersionStage = "AWSCURRENT"
    };

    GetSecretValueResponse response = await _secretsManager.GetSecretValueAsync(request);
    return Ok(new { Secret = response.SecretString });
}

Here, we instantiate the GetSecretValueRequest object assigning the SecretId for the secret that we are trying to fetch and also ask for the latest version of the secret by setting the VersionStage to AWSCURRENT. The last step is to send the request and parse the response.

Let’s take a look at the complete SecretController class.

using Amazon.SecretsManager;
using Amazon.SecretsManager.Model;
using Microsoft.AspNetCore.Mvc;

namespace Api.Controllers;

[ApiController]
[Route("[controller]")]
public class SecretController : ControllerBase
{
    private readonly IAmazonSecretsManager _secretsManager;

    public SecretController(IAmazonSecretsManager secretsManager)
    {
        _secretsManager = secretsManager;
    }

    [HttpGet]
    public async Task<IActionResult> GetSecret()
    {
        GetSecretValueRequest request = new GetSecretValueRequest
        {
            SecretId = "test-secret",
            VersionStage = "AWSCURRENT"
        };

        GetSecretValueResponse response = await _secretsManager.GetSecretValueAsync(request);
        return Ok(new { Secret = response.SecretString });
    }
}

Testing the Application

First, let’s get the "Api" application up and running with the following .NET CLI command:

$ dotnet run ––project Api/

*Note, here we have configured the app to run on port 5000. Your app port may very.

In your favorite browser, let’s navigate to http://localhost:5000/secret. You should see something like the following:

{
   "secret": "txRxQ6#[Muq_%oVVg,0vLrDJ;7{GG^Gy"
}

Keep the browser open for a test after we practice a couple more commands.

Let’s go back to the CLI and create a new password to store.

$ aws secretsmanager get-random-password

Again, you should see something like the following:

{
   “RandomPassword”: “0)r}|iRvK2H,%<R9tAJNDu<M@gw*OUD-”
}

Copy the generated password and then let’s update the secret like so:

$ aws secretsmanager put-secret-value \
    ––secret-id test-secret \ 
    ––secret-string ‘0)r}|iRvK2H,%<R9tAJNDu<M@gw*OUD-’

On completion, you will see a response with values for ARN, Name, VersionId, and VersionStages.

Let’s return to the browser and give it a refresh. If you closed the browser, just reopen the browser and browse to: http://localhost:5000/secret. You should now see the value you just entered for the secret and the response should look something like this:

{
   "secret": "0)r}|iRvK2H,%<R9tAJNDu<M@gw*OUD-"
}

With our tests complete, let’s delete that secret.

$ aws secretsmanager delete-secret ––secret-id test-secret

Summary

That’s it! We have concluded this post where we went over reading AWS Secrets Manager secrets from within a .NET application as well as creating, updating and deleting secrets in AWS Secrets Manager via the AWS CLI.

Use AWS Systems Manager Parameter Store as a .NET Configuration Provider

Kurt Feeley — Tue, 17 May 2022 14:50:11 +0000

Over the last few years, Microsoft has made many changes to improve your configuration management strategy in .NET. Long gone are the days where you have limited configuration options. In .NET, there are now out of the box options for INI, JSON, XML, command-line arguments, in-memory stores, environment variables and key-per-file, et al. And, if those options weren’t enough, custom configuration providers can be developed. Here, we'll focus on a configuration provider built by AWS that integrates with what my colleague calls the Swiss Army Knife for AWS configuration management -- AWS Systems Manager Parameter Store.

AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data as well as secrets. With AWS Systems Manager Parameter Store, you can securely store things like passwords and secrets, but also database connection strings, UNC network paths, URLs and the like.

Photo by Patrick on Unsplash

The Solution

In this tutorial, we’ll take a look at a .NET configuration provider developed by AWS that integrates with AWS Systems Manager Parameter Store. We'll develop a .NET API that we'll use to read configuration data from Parameter Store and we'll use the AWS CLI to seed that configuration data.

Prerequisites

To complete this solution, you will need the .NET CLI which is included in the .NET 6 SDK. In addition, you will need to download the AWS CLI and configure your environment. You will also need to create an AWS IAM user with programmatic access with the appropriate permissions to create and read parameters in AWS Systems Manager Parameter Store.

Warning: some AWS services may have fees associated with them.

The Dev Environment

This tutorial was developed using Ubuntu 20.04, AWS CLI v2, .NET 6 SDK and Visual Studio Code 1.66.2. Some commands/constructs may very across systems.

Create the Config Data with the AWS CLI

First, let’s use the AWS CLI to create a few parameters in Parameter Store.

$ aws ssm put-parameter ––name=/testapp/test-key \
     ––value=test-value ––type=String

$ aws ssm put-parameter ––name=/testapp/test-key2 \
     ––value=test-value2 ––type=String

$ aws ssm put-parameter ––name=/testapp2/test-key3 \
     ––value=test-value3 ––type=String

* Notice the difference between the first two parameters and the last one?

Develop the Test App

Now that we have some parameters in the Parameter Store, let’s create an application that will pull the key/value data as configuration. For this, we will use a simple API to illustrate the process. Use the following command to create a stubbed out .NET API:

$ dotnet new webapi ––name Api

With the API in place, we now need to pull in the AWS Nuget package that contains the configuration provider for AWS Systems Manager Parameter Store. Use the following command to add the package reference:

$ dotnet add Api/ \
     package Amazon.Extensions.Configuration.SystemsManager

The next step is to modify the Program.cs file to wire up the new configuration provider. Let’s modify Program.cs by adding the following line just below the builder variable declaration:

builder.WebHost.ConfigureAppConfiguration(
                c => {

                    c.AddSystemsManager(source =>{
                        source.Path = "/testapp";
                        source.ReloadAfter =
                            TimeSpan.FromMinutes(10);
                    });
                }
            );

The Program.cs file should now look like:

var builder = WebApplication.CreateBuilder(args);

builder.WebHost.ConfigureAppConfiguration(
                c => {

                    c.AddSystemsManager(source =>{
                        source.Path = "/testapp";
                        source.ReloadAfter =
                            TimeSpan.FromMinutes(10);
                    });
                }
            );

builder.Services.AddControllers();
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

app.UseAuthorization();

app.MapControllers();

app.Run();

So far, we have created a simple API and brought in a package that allows us to use AWS Parameter Store as a configuration store. The next step is to create a controller so that we can view the configuration data that is fetched from AWS Parameter Store. This exercise is obviously for demonstration purposes only and not based on a true use case.

Let’s go into the Controllers folder and create a file named, ParametersController.cs, following the standard structure of a controller class. In this file we’ll create a method named, GetParameter and we’ll complete the method and class like so:

using Microsoft.AspNetCore.Mvc;

namespace Api.Controllers;

[ApiController]
[Route("[controller]")]
public class ParameterController : ControllerBase
{
    private IConfiguration _configuration;

    public ParameterController(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    [HttpGet]
    public IActionResult GetParameter()
    {

        string parameter1 = _configuration["test-key"];
        string parameter2 = _configuration["test-key2"];
        string parameter3 = _configuration["test-key3"];

        return Ok(new List<string> { parameter1, parameter2, parameter3 });

    }
}

With the controller complete, we should be ready to test our application. Let’s start the application with the following command:

$ dotnet run ––project Api/

*Note, here we have configured the app to run on port 5000. Your app port may very.

Now that the application is running, let’s navigate to, http://localhost:5000/Parameter in your favorite browser. You should see a response that looks something like this:

[
    "test-value",
    "test-value2",
    null
]

Notice that test-value3 is not present. This is because when we set up our configuration provider in Program.cs, we set the path to “/testapp”. By setting the path, Parameter Store is going to give us all parameters that are prefixed with the /testapp path. When creating the third parameter, we used a path of /testapp2, which causes the third parameter to be omitted.

Summary

We have completed the tutorial, learning to create data in AWS Systems Manager Parameter Store via the AWS CLI as well as creating an application in AWS.NET to pull the configuration data from AWS Systems Manager Parameter Store.

Three Steps to Create a .NET AWS Lambda Function with an HTTPS Endpoint

Kurt Feeley — Mon, 02 May 2022 16:33:43 +0000

AWS Lambda, which has often been credited as changing the way that we think about software and how we architect software, arrived in 2015 with much fanfare. Years later, Lambda's use continues to grow and AWS is still adding features.

If there had been one complaint by software developers, engineers, architects and the like, it is the one obvious missing feature -- a URL that could be assigned directly to an AWS Lambda function. Now, let's be honest, AWS API Gateway integrates with AWS Lambda and the process of integration is pretty straightforward. But, wouldn't it be nice to check a box in the AWS console and have a URL assigned to your Lambda function? Well, the wait is over, because that's exactly the feature that AWS recently released for Lambda.

Photo by Bonnie Kittle on Unsplash

The Solution

In this tutorial, we will build a simple .NET Lambda function that will be invoked from a URL. When invoked, the Lambda function will read any query string parameters in the URL and return a JSON array of the query string parameter values. In addition, we will create the AWS Lambda function, the Lambda function URL, the Lambda function execution role, and the supporting policies using the the AWS CLI.

Prerequisites

To complete this tutorial, you will need the .NET CLI which is included in the .NET 6 SDK. In addition, you will need to download the AWS CLI and configure your environment. You will also need to create an IAM user with programmatic access to AWS Lambda and IAM with the appropriate permissions to create and modify Lambda functions, create Lambda function URLs, create IAM roles and IAM policies.

Warning: some AWS services may have fees associated with them.

This tutorial was developed using Ubuntu 20.04, AWS CLI v2, .NET 6 SDK and Visual Studio Code 1.66.2. Some commands/constructs may very across systems.

"To create a function, you need a deployment package and an execution role." — docs.aws.amazon.com

1) Creating a Lambda Deployment Package

Developing a .NET AWS Lambda Function

To keep our Lambda function lean, we will start with a .NET class library. We can create the .NET class library with the following command:

$ dotnet new classlib -n LambdaWithUrl

With the .NET class library created, let's change the directory to the newly created project folder, LambdaWithUrl and add the package dependencies like so:

$ dotnet add package Amazon.Lambda.APIGatewayEvents

$ dotnet add package Amazon.Lambda.Serialization.Json

$ dotnet add package Amazon.Lambda.Core

$ dotnet add package AWSSDK.Lambda

Ok, now that we have the bones of the Lambda function in place, let’s get into the code. For this tutorial, the code will be very concise.

We are going to create one class named, “Handler”, that has one method named, “Handle”. When the Lambda function is invoked, the Handle method will be called and it will process the data that is passed in from AWS Lambda. Since we are going to be invoking this Lambda via a URL, the method parameter type of the Handle method will be APIGatewayProxyRequest. To get an idea of the data that can be processed by the Lambda function, checkout an example JSON Payload or the C# APIGatewayProxyRequest class.

The Lambda function processing logic is simple in this tutorial. Essentially, when this Lambda function is invoked, the query string values will be plucked out and returned. Consumers of this Lambda function’s URL will receive a JSON array of strings containing the values from the query string parameters that were used to invoke the function.

Here’s the Handler class in its entirety.

using Amazon.Lambda.Core;
using Amazon.Lambda.APIGatewayEvents;
using Amazon.Lambda.Serialization.Json;

namespace LambdaWithUrl;

public class Handler
{
    [LambdaSerializer(typeof(JsonSerializer))]
    public IEnumerable<String> Handle(APIGatewayProxyRequest apiGatewayProxyRequest)
    {
        return apiGatewayProxyRequest?.QueryStringParameters?.Values ?? new String[0];
    }
}

That's it for the coding of our simple .NET AWS Lambda function.

Packaging the .NET AWS Lambda Function

For this tutorial, we will create a zip file deployment package of our .NET Lambda function.

The first step is to publish the .NET application using the following .NET CLI command. Notice the MSBuild GenerateRuntimeConfigurationFiles parameter. Setting GenerateRuntimeConfigurationFiles to true will instruct the .NET CLI to generate the (appname).runtimeconfig.json file that AWS Lambda requires.

$ dotnet publish \
   -c Release \
   -o lambda \
   /p:GenerateRuntimeConfigurationFiles=true

Let’s change the directory to the “lambda” directory and zip all the directory’s contents with the following command. There are many options to zip files across Windows, Linux and macOS. Here you will see the command that was used in the Ubuntu environment. Whichever option you choose, make sure you zip the contents of the folder and not to include the folder in the zip file. Also notice that the lambda.zip file is placed in the LambdaWithUrl directory, which is important for a forthcoming step.

$ zip ../lambda.zip *

That’s it, our AWS Lambda function is packaged and ready to be uploaded.

2) Set Permissions

Create the Lambda Function Execution Role

With the deployment package set to go, we can turn our attention to the execution role.

The execution role has two policies. The trust policy defines what principal can use or assume the role. The second policy defines the AWS services and resources in which the role has access to.

Let’s change the directory back to the project directory (LambdaWithUrl) and create a file named trust-policy.json with the following content.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "lambda.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Let’s use the following command to create the execution role, using the trust-policy.json file to create the trust policy.

$ aws iam create-role \
   --role-name lambda-with-url-execution-role \
   --assume-role-policy-document file://trust-policy.json

With the role created, let’s define the permissions for the Lambda function. You could create your own policy and attach it, but for this tutorial we’ll attach the AWS AWSLambdaBasicExecutionRole managed policy. The AWSLambdaBasicExecutionRole simply will grant the Lambda function permission to create logs in Amazon CloudWatch.

Let’s use the following command to attach the AWSLambdaBasicExecutionRole policy.

$ aws iam attach-role-policy \
   --role-name lambda-with-url-execution-role \
   --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

And, with that, the Lambda function execution role is complete.

3) Configure the Lambda Function with the CLI

Create the .NET Lambda Function

With the Lambda function execution role completed and the deployment package ready to be uploaded, let’s create the Lambda function using the AWS CLI with the command below, replacing aws-account-number with your AWS account number.

$ aws lambda create-function  \
   --function-name lambda-with-url  \
   --runtime dotnet6  \
   --handler LambdaWithUrl::LambdaWithUrl.Handler::Handle  \
   --description lambda-function-with-url  \
   --zip-file fileb://lambda.zip  \
   --role arn:aws:iam::(aws-account-number):role/lambda-with-url-execution-role

When completed, you should get a response with a JSON object with elements of FunctionName, FunctionArn, Runtime, etc.

Create the Lambda Function URL

The last step is to create a URL for the Lambda function. This can be done in two parts. Note: for this tutorial we allow public access and set function-url-auth-type to NONE. Scrutinize your security needs and set the URL permissions accordingly.

First, we need to create the Lambda URL and we can do so with this command:

$ aws lambda create-function-url-config  \
   --function-name lambda-with-url  \
   --auth-type NONE

When completed, you should get a response with a JSON object with elements of FunctionUrl, FunctionArn, AuthType, etc.

Record the FunctionUrl for testing.

Finally, we need to set permissions in order to access the URL.

$ aws lambda add-permission  \
   --function-name lambda-with-url  \
   --statement-id FunctionURLAllowPublicAccess  \
   --action lambda:InvokeFunctionUrl  \
   --principal "*"  \
   --function-url-auth-type NONE

When completed, you should get a response with a JSON object with the element of Statement.

OK, the Lambda function has been created along with the associated URL. The next step is to give the .NET Lambda function a test using its URL.

Testing the .NET AWS Lambda Function

Open a browser and browse to the Lambda URL that you recorded earlier. You should see an empty JSON array — [ ]. Append the following to the end of the URL and hit enter:

?param1=value1&param2=value2

Once the page loads, you should see the following response.

[
   "value1",
   "value2"
]

Summary

We have concluded this tutorial where you have learned how to build a .NET Lambda function with an associated URL. You also learned how to create an IAM role and attach an IAM policy using the AWS CLI.

*** Don't forget to remove any unwanted AWS resources that were created for this tutorial ***