Skip to content
This repository has been archived by the owner on Jun 4, 2021. It is now read-only.

Feature Request: Add destruction capabilities #475

Closed
mjrlee opened this issue Jan 9, 2017 · 5 comments
Closed

Feature Request: Add destruction capabilities #475

mjrlee opened this issue Jan 9, 2017 · 5 comments

Comments

@mjrlee
Copy link
Contributor

mjrlee commented Jan 9, 2017

For those unfamiliar with AWS, removing the created instance might be a bit tricky, this could be automated.

I've created a destroy branch at: https://github.com/MartinLeeUK/streisand/tree/destroy

Before I submit a pull request, is this needed? Is there a better approach?

@bryan4887
Copy link

I agree; this would be a very convenient feature.

@cpu
Copy link
Collaborator

cpu commented Apr 7, 2017

@MartinLeedotOrg Is this request specific to AWS or a general ask? I'd like to update the title if it is AWS specific.

@lazerhawk
Copy link

Are you suggesting some sort of internal self destruct feature, where if a condition specified at creation is reached, the instance becomes unavailable to VPN users and prepares to remove internal data in some manner?

A timer based condition would be interesting, perhaps a deadman's switch? This ties into the issue of how old an instance should be, such as an instance that was left running for a long time using an Ubuntu LTS instance that may have reached end of OS support (LTS). See #513

Other conditions, like watching a version management file or canary file (but no access due to 404 might end up being a DoS)

There is the two main issues of how far should a self-destruct go though.

  1. How far to destroy internally; removing assorted VPN keys and logs, write zeros to freed space, but perhaps leave the ssh keys for connectivity for final remediation?

  2. How far to destroy externally; stopping and removing the VM instance, but this may require cached cloud provider credentials if attempting to execute internally from the VM which is a major leakage issue. Doing it externally would require the original creation source OS to schedule something like a cron job or similar, but again the caching of credentials becomes problematic. Would this start to become AWS IAM tricks, like deploying a single instance management user with self destruct capability for only that instance?

@mjrlee
Copy link
Contributor Author

mjrlee commented Apr 11, 2017

So, I was more thinking of just extending the script to tear down instances once you're done with them. It's not intuitive in AWS, especially for a novice.

As I said, check out the feature branch at https://github.com/MartinLeeUK/streisand/tree/destroy - I've already made the playbook and role for AWS.

@cpu
Copy link
Collaborator

cpu commented Jul 23, 2017

Closing in favour of #475

@cpu cpu closed this as completed Jul 23, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants