Kong 2.8.x warning on Startup w Postgres: resty.openssl.auxiliary.nginx is using plain FFI and it's only intended to be used in development

[jeremyjpj0916]

We build Kong Gateway from nginx/openresty source and luarocks kong and we are running into a bit of logs that bother me since moving from C* to Postgres.

First of all, the output of Kong context during all the startup/runtime contains this:

2024/04/18 21:25:23 [warn] 43#0: *4 [lua] nginx.lua:300: get_ngx_ssl_from_socket_ctx(): note resty.openssl.auxiliary.nginx is using plain FFI and it's only intended to be used in development, consider using lua-resty-openssl.aux-module in production., context: ngx.timer

In Kong 2.8.1 series we install pgmoon like so in a later luarocks install command post build:
---Needed to fix errors around starting against postgres.---
&& luarocks install pgmoon 1.16.0 --force

I believe Kong put out their own modified version of pgmoon fork too but I don't see it used in the OSS kong builds in the 2.8.1 version so maybe that is not the direction I need to look.

The meat of how we build Kong is:

RUN cd /sg-kong-build-tools/openresty-build-tools
&& mkdir work
&& ./kong-ngx-build -p $KONG_PATH
--openresty $RESTY_VERSION
--openssl $RESTY_OPENSSL_VERSION
--luarocks $RESTY_LUAROCKS_VERSION
--add-module /ModSecurity-nginx
--pcre $PCRE_VERSION
--force

#Symlink to luarocks executable and nginx executable
RUN ln -s $KONG_PATH/luarocks/bin/luarocks /usr/bin/luarocks --force
RUN ln -s $KONG_PATH/openresty/nginx/sbin/nginx /usr/bin/nginx

#Install Kong via luarocks
RUN luarocks install kong 2.8.1-0 OPENSSL_DIR=/sg-kong-build-tools/openresty-build-tools/work/openssl-$RESTY_OPENSSL_VERSION OPENSSL_LIBDIR=/sg-kong-build-tools/openresty-build-tools/work/openssl-$RESTY_OPENSSL_VERSION CRYPTO_DIR=$KONG_PATH/openssl

#Get the Kong executable resty script
RUN wget https://raw.githubusercontent.com/Kong/kong/$KONG_VERSION_TAG/bin/kong -P /usr/bin
RUN chmod 777 /usr/bin/kong
RUN mv $KONG_PATH/openresty/bin/resty /usr/bin

#Hit permissions issue first build getting into /user/local/kong so trying this
RUN chmod -R 777 /usr/local/kong
######------ END KONG BUILD TOOLS APPROACH ------######

Originally made an enterprise ticket asking about that error to which I got some helpful info that may clear issue up for me:
"
I had a look at the error and the portion of the code that triggers it:

https://github.com/Kong/lua-resty-openssl/blob/3c79a57e6bace1351caa621746a05ae74b6bf578/lib/resty/openssl/auxiliary/nginx.lua#L167

local NO_C_MODULE_WARNING_MSG_SHOWN = false
local NO_C_MODULE_WARNING_MSG = "note resty.openssl.auxiliary.nginx is using plain FFI " ..
"and it's only intended to be used in development, " ..
"consider using lua-resty-openssl.aux-module in production."

local function get_ngx_ssl_from_req()
if not NO_C_MODULE_WARNING_MSG_SHOWN then
ngx.log(ngx.WARN, NO_C_MODULE_WARNING_MSG)
NO_C_MODULE_WARNING_MSG_SHOWN = true
end

To remedy the above condition, I expect you'll need to install the following:

https://github.com/fffonion/lua-resty-openssl-aux-module

Based on the documentation there, once it is installed, lua-resty-openssl will automatically pick up on it and the error should no longer occur
"

Maybe fffonion has some familiarity around this scenario? Our Kong runtime even with the warning seems to be doing fine and dandy talking to a postgres 14 cluster over TLS 1.2 regardless. But do wanna follow best practice and hopefully get this warning put away and documented here if any other OSS users come across this warning.

Going back to days of 2.8.1 builds I see:
https://github.com/Kong/kong-build-tools/blob/master/openresty-build-tools/kong-ngx-build#L787

Which has flag if Kong is an enterprise build then use dynamic module in the compile steps. Does this mean that non-enterprise builds will always throw this flag? Maybe I am missing where OSS Kong fixed the warning? Anyone weigh in on how I can fix this issue in OSS? Does it have to happen at compile time or is there a simple luarocks install I can add post compile that will resolve that warning?

[jeremyjpj0916]

Looking forward to eventually refactoring this beast to using the bazel build flows once we move to Kong 3.x series but for now getting that warning resolved is a priority while still on Kong 2.8.x

[jeremyjpj0916]

I think this would be the secret sauce? Any feedback is appreciated.

Usually w the mod security module I did not have to run the make installs post add-module like the docs of this lib recommend, but following per docs, otherwise I would have added the make install lines closer to its source pull down for better read visibility.

Also still not sure why it wasn't part of the main OSS build based on the flag I mentioned in the other build process? Seems like this lib would have been needed for OSS too to avoid these warnings unless there is a different patching spot or something I didn't see going down for 2.8.1 .

[jeremyjpj0916]

Looks like that seems to have fixed it from throwing that error output!

nginx: [warn] load balancing method redefined in /usr/local/kong/nginx.conf:164
time="2024-04-19T00:16:48Z" level=info msg="read crontab: /usr/local/crons/stargate_crons"
2024/04/19 00:16:48 [notice] 26#0: using the "epoll" event method
2024/04/19 00:16:48 [notice] 26#0: openresty/1.19.9.1
2024/04/19 00:16:48 [notice] 26#0: built by gcc 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
2024/04/19 00:16:48 [notice] 26#0: OS: Linux 4.18.0-513.18.1.el8_9.x86_64
2024/04/19 00:16:48 [notice] 26#0: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2024/04/19 00:16:48 [notice] 26#0: start worker processes
2024/04/19 00:16:48 [notice] 26#0: start worker process 41
2024/04/19 00:16:48 [notice] 26#0: start worker process 42
2024/04/19 00:16:48 [notice] 26#0: start worker process 43
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'services' into the core_cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 43#0: *3 [kong] init.lua:312 only worker #0 can manage, context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 42#0: *2 [kong] init.lua:312 only worker #0 can manage, context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'services' into the core_cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [kong] warmup.lua:171 the 'plugins' entity is ignored in the list of 'db_cache_warmup_entities' because Kong pre-warms plugins automatically, context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'consumers' into the cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'consumers' into the cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'acls' into the cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'acls' into the cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'certificates' into the core_cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'certificates' into the core_cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'jwt_secrets' into the cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'jwt_secrets' into the cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:104: single_dao(): Preloading 'oauth2_credentials' into the cache..., context: init_worker_by_lua*
2024/04/19 00:16:48 [notice] 41#0: *1 [lua] warmup.lua:145: single_dao(): finished preloading 'oauth2_credentials' into the cache (in 0ms), context: init_worker_by_lua*
2024/04/19 00:16:49 [notice] 41#0: *22 [lua] warmup.lua:36: warming up DNS entries ..., context: ngx.timer
2024/04/19 00:17:50 [notice] 41#0: *22 [lua] warmup.lua:70: finished warming up DNS entries' into the cache (in 60945ms), context: ngx.timer