6 ms·

There are a few lessons here: 1. Use IAM roles. AWS keys should only have access to the specific functionality they need. Best practice is to never use your ro

by cheald 12y ago

There are a few lessons here: 1. Use IAM roles. AWS keys should only have access to the specific functionality they need. Best practice is to never use your root credentials for anything; always use IAM users and use unique keys for each use case, so that you can invalidate and replace them easily. Every time documentation or a tutorial asks you to insert AWS keys, your response should be "let me go create a role for that" rather than "let me go look those up". 2. More importantly, if you ever accidentally publish or leak credentials, don't try to clean it up by deleting those commits. Invalidate the credentials immediately and re-issue them. 3. Always, always `git diff HEAD` before committing. Know what you're about to push up. This isn't just a security concern - the number of small, stupid things you'll catch that you'd otherwise end up fixing 15 seconds later is substantial. As a bonus, this incentivizes you to keep your commits small and atomic. You might talk to Amazon directly - they've been known to forgive debts like these in these kinds of circumstances.

pktgen 12y ago
> You might talk to Amazon directly - they've been known to forgive debts like these in these kinds of circumstances. They did: > Lucky for me, I explained my situation to Amazon customer support – and they knew I wasn’t bitcoin mining all night. Amazon was kind enough to drop the charges this time…
- cheald 12y ago
  Whoops. I missed that. Glad the author was able to dodge that bullet!
  - jmiwhite 12y ago
    This was my initial reaction too, but I was pleased to find it's just a slightly misleading title :)
    - pbreit 12y ago
      On HN I recall the title originally including the $2300 (which matched the blog post's title). Now the HN title does not include the $ amount. Did the mods make that change? I would think preserving the source's title would generally take precedence even if a bit misleading.
      - jmiwhite 12y ago
        I'm nearly certain it did, which is in line with submission guidelines; certainly the title led to our mutual confusion. I do not know how/if titles can be edited.
brianxq3 12y ago
Huge +1 for #3. Saves my ass all the time. I usually stage the changes I think I want to commit and use `git diff --staged` to confirm before I commit.
- cheald 12y ago
  I like that better - I think I'll start using it. I usually end up staging the stuff I want to commit and reverting the stuff I don't, but that offers better flexibility. Thanks!
JoshTriplett 12y ago
> Always, always `git diff HEAD` before committing. I prefer to always "git commit -v", which shows me the diff while I edit the commit message.
- dperfect 12y ago
  Call me unsophisticated, but I personally find it extremely helpful to use a GUI (currently using SourceTree) to interactively review changes before committing. I use the command line for almost everything else, but this is one of those cases where a nice GUI really seems to shine.
  - csixty4 12y ago
    That's how I work these days as well. SourceTree for commits, especially if I just want to stage hunks instead of whole files. Command line for everything else.
  - fletchowns 12y ago
    SourceTree seems like such a complicated mess. `git gui` and `gitk` are my preference.
    - shortstuffsushi 12y ago
      Funny, I ended up with SourceTree because it seemed like a clean and simple (well, at least when I started with it), but still having all the tools I needed, alternative. Sure, it has gotten a bit more complex, but the basic functionality (as I see it: diff, stage, commit, push, pull, branch management) feels simple to me. Could you explain what parts of it you don't like? Also, could you link to git gui? I tried to Google it, but didn't really get good results (shockingly, all the other Git GUI programs came up...).
      - fletchowns 12y ago
        Here's the tool I was referencing: http://git-scm.com/docs/git-gui http://git-scm.com/docs/git-gui It just seemed so confusing compared to the other tools I mentioned, and it would try to do all this extra stuff for you automatically (i.e. adding weird extra arguments to the git commands and I had no idea what they did)
matchagaucho 12y ago
Heroku doesn't require a public GitHub account. Seems like the best lesson learned is keep personal work personal, use private repos if using GitHub.
- snuxoll 12y ago
  Or, if you don't want to pay for the privilege of not having your work public, go use Bitbucket.
- cheald 12y ago
  Heroku doesn't require any Github account - that's the beauty of git :) That said, I'd still argue that you should practice defense-in-depth; plan for "this is how I'll limit damage when someone gets ahold of these credentials" rather than "Nobody will get these, so I can do dangerous things with them". It's the same argument behind "don't do things as root unless you have no other choice"; trading security for convenience works really nicely right up to the point where you get your teeth kicked in.
- encoderer 12y ago
  *use bitbucket
- serge2k 12y ago
  No, the lesson is don't commit credentials and if they leak then revoke them immediately. and use least privilege to make sure that if you do screw up it's as minor as possible.
  - numbsafari 12y ago
    +1 - Even if you are using a private repo within your company, committing credentials is foolishness. It's trivial for someone to intentionally or unintentionally leak them, or abuse them. And personally, I've found that it's just good practice to exercise those kinds of precautions for "throw-away" projects regardless of their "throw-away" status. It keeps you honest.
alecco 12y ago
About IAM... I worked with that a LOT a couple of years ago. It's interesting but quite the rabbit hole of configurations and permissions. I used to be an AWS fanatic and got burned. Unless you need to scale up on the spot (and have the time to code management of that) it's a huge waste of time for no good price. EC2 instances have dismal performance. Just get decent servers somewhere. For most scenarios it's hard to max out a server nowadays, if you program decently. You have to do that for AWS 10x anyways, IMHE. The cloud is a black hole of developer time and problems. On top of that it's stupid to put data in US when you are a foreign company, you are open game for 3 letter agencies no questions asked.
- aceperry 12y ago
  I really have to wonder about the amount of time to setup your own servers. I like to setup and tweak hardware for fun. But the time and starting costs seems way too much compared to spinning up a few instances to get something going quickly. Looking around here, San Francisco bay area, I can't find any way to host a server as inexpensively and as quickly as I can on the cloud. Plus there are lots of alternatives to AWS which promise better performance. BTW, tweaking around with servers can also be a major time sink.
  - alecco 12y ago
    I mean dedicated servers. Usually the provider installs the OS for you and then you take over.
inopinatus 12y ago
Variant on #3: git diff master origin/master just before you git push.
- fphilipe 12y ago
  Or, if your current branch has an upstream, `git diff @{u}`.
nitrogen 12y ago
In addition to git diff, I suggest git add -p and git diff --cached to enhance visibility of changes. I alias them to short mnemonics in my bash configs.
Kiro 12y ago
Sorry for OT but why do you need to add HEAD? I always just do git diff. I tried to google but didn't find any good answer.
- coldpie 12y ago
  If you do just "git diff" it will show you the diff between the index (staging area) and your working tree. If you do "git diff HEAD" it will show you the difference between the latest commit and your working tree, that is, it includes the diff in the staging area.

by cheald 12y ago

pktgen 12y ago

> You might talk to Amazon directly - they've been known to forgive debts like these in these kinds of circumstances. They did: > Lucky for me, I explained my situation to Amazon customer support – and they knew I wasn’t bitcoin mining all night. Amazon was kind enough to drop the charges this time…

cheald 12y ago
Whoops. I missed that. Glad the author was able to dodge that bullet!
- jmiwhite 12y ago
  This was my initial reaction too, but I was pleased to find it's just a slightly misleading title :)
  - pbreit 12y ago
    On HN I recall the title originally including the $2300 (which matched the blog post's title). Now the HN title does not include the $ amount. Did the mods make that change? I would think preserving the source's title would generally take precedence even if a bit misleading.
    - jmiwhite 12y ago
      I'm nearly certain it did, which is in line with submission guidelines; certainly the title led to our mutual confusion. I do not know how/if titles can be edited.

brianxq3 12y ago

Huge +1 for #3. Saves my ass all the time. I usually stage the changes I think I want to commit and use `git diff --staged` to confirm before I commit.

cheald 12y ago
I like that better - I think I'll start using it. I usually end up staging the stuff I want to commit and reverting the stuff I don't, but that offers better flexibility. Thanks!

JoshTriplett 12y ago

> Always, always `git diff HEAD` before committing. I prefer to always "git commit -v", which shows me the diff while I edit the commit message.

dperfect 12y ago
Call me unsophisticated, but I personally find it extremely helpful to use a GUI (currently using SourceTree) to interactively review changes before committing. I use the command line for almost everything else, but this is one of those cases where a nice GUI really seems to shine.
- csixty4 12y ago
  That's how I work these days as well. SourceTree for commits, especially if I just want to stage hunks instead of whole files. Command line for everything else.
- fletchowns 12y ago
  SourceTree seems like such a complicated mess. `git gui` and `gitk` are my preference.
  - shortstuffsushi 12y ago
    Funny, I ended up with SourceTree because it seemed like a clean and simple (well, at least when I started with it), but still having all the tools I needed, alternative. Sure, it has gotten a bit more complex, but the basic functionality (as I see it: diff, stage, commit, push, pull, branch management) feels simple to me. Could you explain what parts of it you don't like? Also, could you link to git gui? I tried to Google it, but didn't really get good results (shockingly, all the other Git GUI programs came up...).
    - fletchowns 12y ago
      Here's the tool I was referencing: http://git-scm.com/docs/git-gui http://git-scm.com/docs/git-gui It just seemed so confusing compared to the other tools I mentioned, and it would try to do all this extra stuff for you automatically (i.e. adding weird extra arguments to the git commands and I had no idea what they did)

matchagaucho 12y ago

Heroku doesn't require a public GitHub account. Seems like the best lesson learned is keep personal work personal, use private repos if using GitHub.

snuxoll 12y ago
Or, if you don't want to pay for the privilege of not having your work public, go use Bitbucket.
cheald 12y ago
Heroku doesn't require any Github account - that's the beauty of git :) That said, I'd still argue that you should practice defense-in-depth; plan for "this is how I'll limit damage when someone gets ahold of these credentials" rather than "Nobody will get these, so I can do dangerous things with them". It's the same argument behind "don't do things as root unless you have no other choice"; trading security for convenience works really nicely right up to the point where you get your teeth kicked in.
encoderer 12y ago
*use bitbucket
serge2k 12y ago
No, the lesson is don't commit credentials and if they leak then revoke them immediately. and use least privilege to make sure that if you do screw up it's as minor as possible.
- numbsafari 12y ago
  +1 - Even if you are using a private repo within your company, committing credentials is foolishness. It's trivial for someone to intentionally or unintentionally leak them, or abuse them. And personally, I've found that it's just good practice to exercise those kinds of precautions for "throw-away" projects regardless of their "throw-away" status. It keeps you honest.

alecco 12y ago

About IAM... I worked with that a LOT a couple of years ago. It's interesting but quite the rabbit hole of configurations and permissions. I used to be an AWS fanatic and got burned. Unless you need to scale up on the spot (and have the time to code management of that) it's a huge waste of time for no good price. EC2 instances have dismal performance. Just get decent servers somewhere. For most scenarios it's hard to max out a server nowadays, if you program decently. You have to do that for AWS 10x anyways, IMHE. The cloud is a black hole of developer time and problems. On top of that it's stupid to put data in US when you are a foreign company, you are open game for 3 letter agencies no questions asked.

aceperry 12y ago
I really have to wonder about the amount of time to setup your own servers. I like to setup and tweak hardware for fun. But the time and starting costs seems way too much compared to spinning up a few instances to get something going quickly. Looking around here, San Francisco bay area, I can't find any way to host a server as inexpensively and as quickly as I can on the cloud. Plus there are lots of alternatives to AWS which promise better performance. BTW, tweaking around with servers can also be a major time sink.
- alecco 12y ago
  I mean dedicated servers. Usually the provider installs the OS for you and then you take over.

inopinatus 12y ago

Variant on #3: git diff master origin/master just before you git push.

fphilipe 12y ago
Or, if your current branch has an upstream, `git diff @{u}`.

nitrogen 12y ago

In addition to git diff, I suggest git add -p and git diff --cached to enhance visibility of changes. I alias them to short mnemonics in my bash configs.

Kiro 12y ago

Sorry for OT but why do you need to add HEAD? I always just do git diff. I tried to google but didn't find any good answer.

coldpie 12y ago
If you do just "git diff" it will show you the diff between the index (staging area) and your working tree. If you do "git diff HEAD" it will show you the difference between the latest commit and your working tree, that is, it includes the diff in the staging area.