OpenResty Authorization towards ELK APIs using LUA

What is Openresty?

OpenResty is the fifth most-used web server worldwide. It is a superset of the NGINX web server bundled with LuaJIT, which is a compiler for the LUA scripting language. One of the main benefits of OpenResty is that it is highly efficient in terms of CPU and memory usage. What OpenResty excels at is handling a large number of requests with very little CPU usage and high I/O. On the other hand, memory efficiency is mainly achieved by the fact that the application does not fork a process or thread per request connection in comparison to Apache, for example or a typical JVM-based web server. NGINX has some limitations, like the inability to provide a way to use program logical operators or to write custom logic. LUA allows us to go around those limitations. It is known for its speed and for the fact that it makes little demand on the system.

How to make an authorization for APIs using an LUA file?

In our example, we are using OpenResty as the front end for Elasticseach APIs. If you want different users to authenticate towards those APIs using a simple username/password you can do it like that in the main OpenResty configuration file – nginx.conf

location / {
  auth_basic "Elasticsearch Secured API";
  auth_basic_user_file passwords;
 
  access_by_lua_file 'conf/authorize.lua';

This will allow us to list the permissions for the different users granularly in a separate file. The easiest way to write the needed authorizations for a specific user, in other words, what kind of requests can the user make (HEAD, GET, POST, etc.) towards Elasticsearch APIs are from Kibana. If you open the Advanced Kibana WEB UI and click on “Dev Tools” you get to write requests towards different APIs exposed by Elastic. An example can be seen below:

GET /_cat/indices
GET /_cat/nodes
GET /_cat/shards
GET /_nodes
GET /_nodes/process
GET /_nodes/stats/os,process
GET /_cluster/health?level=shards&pretty

The APIs above are the ones between the first two forward slashes, “_cat”, “_nodes“, “_cluster“. We can decide exactly what type of requests a specific user gets to make towards the APIs he/she is supposed to work with. We can be as detailed as we’d like. Let’s take a look at the following authorize.lua file’s content:

test_user = {
  ["/_cat/health"]                            = { "GET" }
  ["/_nodes"]                                 = { "GET" },
  ["/_nodes/http"]                            = { "GET" },
  ["/_cat/aliases/*"]                         = { "GET" },
  ["/*/_search"]                              = { "GET", "POST" },
  ["/_search/scroll"]                         = { "GET", "POST", "DELETE" }
}

The first three authorizations indicate the exact requests our test_user is allowed to make. The results will be the same as if we (the admins) were running the same ones in Kibana ourselves. The fourth one is telling OpenResty that the user can view all aliases for all indexes. The fifth line gives the permissions to make both GET and POST search queries against or to any target in ELK. The last permissions listed allow the user authenticated with its username and password to make 3 types of requests towards the Elasticsearch “_search” API: GET, POST, and DELETE. You can have as many users and permissions listed for every one of those as you’d like. This functionality that LUA adds is pretty useful for managing permissions.

In Conclusion

Using a LUA file for authorization towards APIs can provide a flexible and customizable solution for managing access to an API. Some reasons why one might choose to use a LUA script for API authorization include:

• Dynamic authorization: A LUA script can be used to make authorization decisions based on runtime conditions, such as the user’s role or the current time of day.
• Fine-grained control: It can be used to implement complex authorization rules that go beyond simple allow/deny decisions.
• Reusable code: It can be reused across multiple APIs or applications, making it easier to manage and maintain authorization logic.
• Easier maintenance: LUA files can be easily editable and maintainable, which is useful for updating the authorization rules or adding new ones.
• Compatibility: Depending on the API gateway, LUA scripts can be executed on it, providing a way to use it in the existing infrastructure.

LUA is a great option and choosing it depends on the particular use case, infrastructure, and technical capabilities of the team.

Read more of ITGix’s expert content

Are you looking for a DevOps services provider company that has a proven track record of delivering successful projects in your industry? Look no further! Our case studies provide a detailed look at the various projects we’ve completed for our clients, showcasing our expertise and experience.

From complex technical implementations to streamlined business processes, our case studies demonstrate our ability to understand the unique needs of our clients and deliver tailored solutions that meet those needs. You’ll see how we’ve helped companies like yours to improve efficiency, reduce costs, and increase revenue.