Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Moved the secret_store from S3 to SSM #1123

Closed
wants to merge 3 commits into from
Closed

[core] Moved the secret_store from S3 to SSM #1123

wants to merge 3 commits into from

Conversation

jack1902
Copy link
Contributor

@jack1902 jack1902 commented Feb 12, 2020

to: @ryandeivert @Ryxias
cc: @airbnb/streamalert-maintainers
related to: #240
resolves: #240

Background

Using S3 as a secret_store is no longer desirable. Using SSM Parameter store makes visibility into what secrets are set much easier and requires less setup by StreamAlert

Changes

  • Implemented SSMDriver (a bit of copy&pasta from the S3Driver)
  • Updated unit_tests so they pass when using this new driver
  • Removed secrets bucket creation
  • Added ssm:GetParameter permissions to the alert_processor

Testing

  • ran ./tests/scripts/pylint.sh - currently there are warnings (i aim to clean this code up but want to ensure this initial commit is good)
  • ran ./tests/scripts/unit_tests.sh - All created tests now pass, i need to add some for SSMDriver

[testing] Updated unit_tests to use SSM instead of S3
[terraform] Updated alert_processor permissions so it can pull from
param store

Signed-off-by: jack1902 <39212456+jack1902@users.noreply.github.com>
[testing] Added SSMDriver Tests

Signed-off-by: jack1902 <39212456+jack1902@users.noreply.github.com>
@coveralls
Copy link

coveralls commented Feb 13, 2020

Coverage Status

Coverage decreased (-0.2%) to 95.987% when pulling fad19f3 on jack1902:outputs/move_secret_store_to_ssm into 5ed0583 on airbnb:release-3-1-0.

@Ryxias
Copy link
Contributor

Ryxias commented Feb 14, 2020

The code looks solid.

How would the migration process look? Is there going to be a script? You might need to keep some of the code around to be able to pull from S3 and save into SSM

@jack1902
Copy link
Contributor Author

@Ryxias You raise an interesting point. How should migration scripts be handled. I personally prefer creating a one time script which contains EVERYTHING.

This removes redundant code from the code base and allows for migration scripts to be dropped in future PRs.

What are your thoughts on this? The code removed to pull from S3 can easily be put into a one time script and create a local .JSON file for use with the seperate PR to set-from-file

@ryandeivert
Copy link
Contributor

we could have a subcommand of the outputs cli command temporarily that does this, with the caveat (TODO) that this will be going away in a future release. I could be convinced otherwise, though

This script should be used prior to upgrading to the release which uses
SSM Parameter store as the secret_store. Once you have upgraded, run the
command printed out to the console

Signed-off-by: jack1902 <39212456+jack1902@users.noreply.github.com>
@jack1902
Copy link
Contributor Author

we could have a subcommand of the outputs cli command temporarily that does this, with the caveat (TODO) that this will be going away in a future release. I could be convinced otherwise, though

Consider a script in scripts/ its stand alone ready to be removed. The reason this is better is because the script will currently be on the same release as the move from s3 to ssm. We could move this commit to release-3-0-0 and then have a caveat on moving from release-3-0-0 to release-3-1-0 state, run this script?

@jack1902
Copy link
Contributor Author

Also, @ryandeivert as i can see you have a HUGE PR open currently, that makes a TONNE of changes to the documentation. i would prefer to create a seperate issue to "update" the documentation to reflect these changes after release-3-1-0 is rebased off of release-3-0-0 otherwise we will hit merge conflict city and no one wants that nightmare

Copy link
Contributor

@Ryxias Ryxias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good!

Raises:
ClientError
"""
client = boto3.client('ssm', config=default_config(region=region))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some boto3 clients maintain some sort of "internal state". For example, the athena one (I think?) performs API calls when you first instantiate it. Does SSM use this?

Alternative pattern with this class could be something like:

class AwsSsmClient:

  def __init__(config):
    self._client = boto3.client('ssm', config)

  def get_parameter(parameter_name, with_decryption=True):
    # ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a one time throw away script I'd argue this is good enough as is. Since after the migration is complete this can be thrown away

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous one had this pattern since everywhere it was called was via the staticmethod. i could instantiate this Class within the callers init so it is cached etc between invocations but the parameter/secret that is pulled back is already cached so this seems like complexity for complexities sake



if __name__ == "__main__":
import os
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any particular reason the imports are here instead of at the top of the file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just cleanliness and the fact these are only relevant if name... Since I have to append streamalert to path in order to import it due to the location of the script

region = config["global"]["account"]["region"]
prefix = config["global"]["account"]["prefix"]

bucket_name = f"{prefix}.streamalert.secrets"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subtle thing: @ryandeivert is working on changing the default bucket to include dashes instead of periods. If that PR goes into 3.1.0 you may have to change this to pull from config instead of hardcoding here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice and easy to change if this is the case

# An error occured so exit with code 1
sys.exit(1)

print(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is nice 👍

@jack1902 jack1902 marked this pull request as ready for review February 19, 2020 22:43
@jack1902
Copy link
Contributor Author

I'll pull down release-3-1-0 tomorrow and rebase this work and resolve conflicts

@jack1902
Copy link
Contributor Author

@Ryxias The migration script wouldn't be required if we were to have this in release-3-1-0 as the migration from 2 -> 3 essentially means starting a fresh. I am happy to close this PR and re-open it against release-3-0-0 just wanting to confirm if this will be ok @ryandeivert and @Ryxias ?

@jack1902 jack1902 closed this Feb 20, 2020
@jack1902
Copy link
Contributor Author

Closed in favour of #1142

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants