StackStorm (aka "IFTTT for Ops") is event-driven automation for auto-remediation, incident responses, troubleshooting, deployments, and more for DevOps and SREs. Includes rules engine, workflow, 160 integration packs with 6000+ actions (see https://exchange.stackstorm.org) and ChatOps. Installer at https://docs.stackstorm.com/install/index.html
In https://github.com/StackStorm/stackstorm-k8s/pull/401, I'm adding support for SSL/TLS between internal components of StackStorm. st2auth has out-of-the-box support for SSL/TLS. Meanwhile st2stream and st2api did not and required placing a TLS proxy layer infront of the stream/api containers.
@cognifloyd pointed out in the st2 core code where it should be fairly straightforward to copy the SSL/TLS support from st2auth to st2stream and st2api. This PR does that.
The PR containers two parts as two commits:
Extend SSL/TLS support to st2stream and st2api
This is the primary commit of the PR, it is a basic implementation of SSL/TLS support as suggested by @cognifloyd - and works perfectly fine, nothing fancy beyond that.
Move common API code into shared library
While implementing support for SSL/TLS I notice between the 3 components api, auth and stream that the following set of 3 files for each component:
Are all very similar in function, with only minor functional differences between each one. However there was also some inconsistency in convention between the 3 due to the functionally between separately implement for each (for example auth being the only one with SSL/TLS support).
Therefore in an attempt to "streamline" the code base, I've moved this code into a new separate st2common library openapi (name open to suggestions since this isn't maybe the best description of its function, I just went for this as a "working" name), the library contains 3 files
st2common/st2common/openapi/api.py
st2common/st2common/openapi/app.py
st2common/st2common/openapi/config.py
Which moves the common code from the respectively named files in st2api, st2auth, and st2stream components and updates those libraries to pull in this new library.
This will hopefully simplify support/maintenance going forward - and ensure any new features/fixes that would apply to all 3 components gets implement to all 3 (for example if we had this originally, would we have gotten SSL/TLS support for all 3 components at the same time, instead of just for auth - until this PR?)
As an immediate piece of self-feedback there's a few places in the st2common/openapi library I've done something along the lines of:
if service_name == "foo":
<do_edge_case_for_service_foo>
I don't particularly like that, but these where minor differences between services of an otherwise identical function and I was unsure how to handle it otherwise without having to needlessly replicate code. So any suggestion on how to handle this without having to bake edgecases in the common library would be appreciated.
In https://github.com/StackStorm/stackstorm-k8s/pull/401, I'm adding support for SSL/TLS between internal components of StackStorm.
st2authhas out-of-the-box support for SSL/TLS. Meanwhilest2streamandst2apidid not and required placing a TLS proxy layer infront of thestream/apicontainers.@cognifloyd pointed out in the
st2core code where it should be fairly straightforward to copy the SSL/TLS support fromst2authtost2streamandst2api. This PR does that.The PR containers two parts as two commits:
Extend SSL/TLS support to st2stream and st2api
This is the primary commit of the PR, it is a basic implementation of SSL/TLS support as suggested by @cognifloyd - and works perfectly fine, nothing fancy beyond that.
Move common API code into shared library
While implementing support for SSL/TLS I notice between the 3 components
api,authandstreamthat the following set of 3 files for each component:st2auth:
st2auth/st2auth/config.py st2auth/st2auth/app.py st2auth/st2auth/cmd/api.py
st2api:
st2api/st2api/config.py st2api/st2api/app.py st2api/st2api/cmd/api.py
st2stream:
st2stream/st2stream/config.py st2stream/st2stream/app.py st2stream/st2stream/cmd/api.py
Are all very similar in function, with only minor functional differences between each one. However there was also some inconsistency in convention between the 3 due to the functionally between separately implement for each (for example
authbeing the only one with SSL/TLS support).Therefore in an attempt to "streamline" the code base, I've moved this code into a new separate
st2commonlibraryopenapi(name open to suggestions since this isn't maybe the best description of its function, I just went for this as a "working" name), the library contains 3 filesst2common/st2common/openapi/api.pyst2common/st2common/openapi/app.pyst2common/st2common/openapi/config.pyWhich moves the common code from the respectively named files in
st2api,st2auth, andst2streamcomponents and updates those libraries to pull in this new library.This will hopefully simplify support/maintenance going forward - and ensure any new features/fixes that would apply to all 3 components gets implement to all 3 (for example if we had this originally, would we have gotten SSL/TLS support for all 3 components at the same time, instead of just for
auth- until this PR?)As an immediate piece of self-feedback there's a few places in the
st2common/openapilibrary I've done something along the lines of:I don't particularly like that, but these where minor differences between services of an otherwise identical function and I was unsure how to handle it otherwise without having to needlessly replicate code. So any suggestion on how to handle this without having to bake edgecases in the common library would be appreciated.