With modern clouds, you can build awesome things. You can bring your ideas to life within the hour, enabling experimentation and driving innovation. One of the significant advantages of the cloud is that you get a lot of security controls out of the box. But these security controls can also block you from being productive!
How are these security controls blocking me?
When you use AWS, you can interact with it through the console, sdk, or cli. But these all have one thing in common. They all use the same set of APIs to perform the actions requested by the user. These APIs are protected, and how authentication and authorization are done through the service IAM. When you develop a workload or work on a PoC, you will also use the IAM service.
Assume you want to build an internal API and use the API Gateway service. Enabling IAM authentication on the methods you define is easy. You can then give the appropriate roles access to your API. The consumer of this API only needs to add the AWSSigv4 header, and as long as the role policy allows the invocation of the API, it will work.
Various programming languages can be used to add the signature. But what if you want to test the API from your local machine or the cloud shell from the console? In those cases, you have a shell, and generating the signature becomes much harder. This will impact your productivity.
How can we unblock ourselves?
As explained in the previous section, the challenge is to generate the signature based on the current payload. In the past, I used a simple Python script to perform these API calls, but that always took some time and energy to build. I also felt demotivated when I encountered such situations.
The problem is not the script that you need to write. The problem is that you need to do it repeatedly because each situation is different. This goes against one of my principles, which is to automate everything! There should be a solution to this problem, and the good news is there is one!
Igor Okulist created a small tool called awscurl. This tool allows you to perform a curl command that automatically signs your API call. For example, when we use the scenario described in the previous section, you can simply do the following command:
export AWS_PROFILE=my-profile
awscurl --region eu-west-1 --service execute-api -X GET https://my-url-to-my-api
The example assumes that you have a valid profile configured called my-profile. Then, you do the same command as the original curl command. But you only add a region and a service option to the command. For the comparison, the normal curl command would look like this:
curl -X GET https://my-url-to-my-api
But this command will result in the following error:
{"message": "Missing Authentication Token"}
The awscurl command will inject the Authorization header that looks something like this:
Authorization: AWS4-HMAC-SHA256 Credential=XXX, SignedHeaders=XXX, Signature=XXX
When you try this out yourself, you can add the -v
option, which will print out the headers sent and received. You will see that the API now accepts the signature and responds with the actual results.
You can use it to perform any API call that supports sigv4, but for the majority of services, the AWS cli tool is the best tool for the job. But for your own APIs or calls to your OpenSearch cluster, this tool is definitely a timesaver.
Conclusion
When you develop an internal API or have an OpenSearch cluster that uses IAM for authentication and authorization, testing calls towards these endpoints can be challenging as you will need to create a signature. The awscurl cli tool helps you create this signature, allowing you to focus on your business value instead of building signatures for tests.
Photo by Pixabay