You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's an MSK cluster running with SASL auth. There's a backend producing events and a Serverless application listening to certain topics, using messages to trigger parametrized reactions, such as calling other lambda functions or uploading data to a DB.
The ARN provided to saslScram512 should be associated with the secret created during the SASL setup, described in more detail here. Much like the accessConfigurations field in kafka events works.
The text was updated successfully, but these errors were encountered:
Thanks @pedrocava - it looks great 👍 It will be a bit different than for kafka, where these configurations are nested under accessConfigurations, however, I see that in case of msk the saslScram512 is the only possible configuration which suggests that in this case, nesting under accessConfigurations doesn't make much sense. 👍
Use case description
There's an MSK cluster running with SASL auth. There's a backend producing events and a Serverless application listening to certain topics, using messages to trigger parametrized reactions, such as calling other lambda functions or uploading data to a DB.
Proposed solution
AWS has recently started supporting SASL auth for MSK events. Unfortunately, this feature's documentation in CloudFormation is rather scarce.
Extending the convention @pgrzesik provided here, we should have something like:
The ARN provided to
saslScram512
should be associated with the secret created during the SASL setup, described in more detail here. Much like theaccessConfigurations
field inkafka
events works.The text was updated successfully, but these errors were encountered: