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
{{ message }}
This repository has been archived by the owner on Jan 22, 2023. It is now read-only.
Separating out the permission to create snapshots from deleting snapshots would improve security.
Currently, if this is running in a host and the host is compromised, the attacker would have permissions to delete all the snapshot backups of the host as well as the host itself. Not good.
With the broad recommended IAM permissions, an attacker with access to a single host running this tool could delete snapshots for any host in the AWS cluster.
On the other hand, the ability to for an atttacker to create new snapshots of the machines gains them little.
It's valuable for the "create" function to run within the host, so it can also do things like freeze the filesystem or a database. However, there's no requirement that the "delete" statement be run within the host.
For additional security, all the "snapshot expiration" for your cluster could be run externally. One approach someone used was to combine "Lamda functions" and "Cloudwatch alarms" to run tasks like "cron jobs" that were not tied to a particular host:
I agree with you 100%. In fact, this is a change I've made in my own private branch that I use in production (albeit in very beta/dev/hack quality fashion).
I should have some free time at the end of December to do a complete re-write on this project. Features I would like to include (and that have been requested):
Change the script so that it accepts arguments for which functions should run. For example:
ebs-snaphsot.sh snapshot all
ebs-snapshot.sh snapshot /dev/sda1
ebs-snapshot.sh clean /dev/sda1
ebs-snapshot.sh clean all
Update the recommended IAM policies so that:
a) Regular hosts can only take snapshots
b) Deleting snapshots can only be performed by an Admin server
Redo how logging is done.
Merge in the Docker compatibility that @bkrodgers submitted as a pull request.
Finally, I would like to add an optional filesystem freeze flag to run before taking snapshots.
Anything other suggestions that you have? @jboeshart, any feedback on features that you would like to see as well?
The way I see it, ec2-consistent-snapshot has more options, like filesystem and database freezing, while the benefit of this script is that it has no dependencies. ec2-consistent-snapshot is written in Perl and has quite a few dependencies. They are easily handled by installing the Debian or Ubuntu package, but there's simply more machinery and things to get out of date.
Agreed on the "See Also" section, and with the project's simplicity. This project started because of a very specific use case (very small deployment that needed a simple Bash script to automate snapshots). But as the script's popularity has grown, the community's needs/use-cases have also expanded.
I would like to see this project expand to meet those use-cases, but also maintain its lack of dependencies (i.e. it will always use the AWS CLI and nothing else) while retaining its simplicity.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Separating out the permission to create snapshots from deleting snapshots would improve security.
Currently, if this is running in a host and the host is compromised, the attacker would have permissions to delete all the snapshot backups of the host as well as the host itself. Not good.
With the broad recommended IAM permissions, an attacker with access to a single host running this tool could delete snapshots for any host in the AWS cluster.
On the other hand, the ability to for an atttacker to create new snapshots of the machines gains them little.
It's valuable for the "create" function to run within the host, so it can also do things like freeze the filesystem or a database. However, there's no requirement that the "delete" statement be run within the host.
For additional security, all the "snapshot expiration" for your cluster could be run externally. One approach someone used was to combine "Lamda functions" and "Cloudwatch alarms" to run tasks like "cron jobs" that were not tied to a particular host:
https://forums.aws.amazon.com/thread.jspa?messageID=674123#674123
The text was updated successfully, but these errors were encountered: