This work is compelling. A book I read with analogous ideas was incredibly eye-opening. "AWS Unleashed: Mastering Amazon Web Services for Software Engineers" by Harrison Quill
@pippopeppe83
6 жыл бұрын
Pretty good video with the practical examples and so on. I didn't understand when there is a rotation the previous secret remains still usable for a while or it is immediately removed. In the 2nd option what to happen to the application if it doesn't recover quickly the new secret, lost the database connection? Probably I'll find out in the documention
@johnbrown4200
6 жыл бұрын
Great question, I wondered the same thing. Today I noticed this so I will paste it here. From AWS docs... "Secrets Manager can automatically rotate your secret for you on a schedule that you specify. You can rotate credentials without interrupting the service if you choose to store a complete set of credentials for a user or account, instead of only the password. If you change or rotate only the password, then the old password immediately becomes obsolete, and clients must immediately start using the new password or fail. If you can instead create a new user with a new password, or at least alternate between two users, then the old user and password can continue to operate side by side with the new one, until you choose to deprecate the old one. This gives you a window of time where all of your clients can continue to work while you test and validate the new credentials. Only after your new credentials pass testing do you commit all of your clients to using the new credentials and remove the old credentials."
@kevinmugiira7517
Жыл бұрын
Nice one.
@amazonwebservices
Жыл бұрын
We're glad you like it! 😀 🙌 ☁️
@bob75654
2 жыл бұрын
This was a great walk through thank you!
@clray123
6 жыл бұрын
This makes it so much easier for an attacker who hacked an application and was able to impersonate it to steal all the secrets conveniently through a standardized API rather than having to go looking for them in the environment/filesystem/code/memory...
@pippopeppe83
6 жыл бұрын
First, the attacker needs to know that secret manager is in use so it is like another place. Second, he can also steal the secret/s but in a period of time, they are rotated so if the application is fixed he lost the secrets.
@clray123
6 жыл бұрын
Well, the secrets manager itself is not secret, so it's trivial for the attacker to make that API call on application's behalf (and that again is trivial using the "short-lived" application credentials attached to EC2 instance), just to see whether there's something's there or not. That's my point - it might be "another place", but it's a very well known place, even more exposed than some application-specific location in the file system. Worse yet, given that it's such a central location, chances are that other secrets (not really relevant to the application) may be deposited in the same place and the application accidentally permitted to be able to read them as well. As for the rotation of secrets, it's a completely separate issue - whether you use a secrets manager or not, you can rotate your secrets (or not). Anyhow, I'd expect the attacker to steal any data that he can from the compromised system immediately, using the then active credentials obtained from secrets manager. So secrets rotation does not really offer that much protection.
@pippopeppe83
6 жыл бұрын
I really didn't understand your reply. Anyway, try to think like that: if your application has access only to its passwords and not others and get hacked have secrets manager with rotation is for sure better than have the passwords in some place inside the machine without any rotation.
@clray123
6 жыл бұрын
Let me put it that way, having secrets in the machine is like hiding valuables in weird places in your house. Of course, professional burglars will know where to look for them. Having a secrets manager is like having a big safe. And hanging a key to that safe right behind your front door. Any idiot will be able to unlock it. The only benefit I can see is that because of the remote logging you will know sooner that it was unlocked and all your data stolen.
@pippopeppe83
6 жыл бұрын
Ok we have for sure very different option.
@chriskondiah741
2 жыл бұрын
So what I get here is we do a custom glue connection and link it to the jar file secrets manager generates? Then use that connector in either studio or data brew?
@velunatarajan2649
4 жыл бұрын
Where to get Lambda function snippet used for key rotation?
@amanbabbar1709
6 жыл бұрын
Hi apurv I tried to implemant your tutorial on how to access secrets across aws accounts by attaching resource based policy but could not able to use it. Let me know the steps of creating iam role with secret key policy for this.
@DevasishGhosh
3 жыл бұрын
At timeline 23:20 - I have a question regarding the python secret manager client side caching library : When the secrets are rotated automatically but in the client side still the older secret is cached will the cached version work?
@johnbrown4200
6 жыл бұрын
Well done, easy to understand and follow.
@radu2329
3 жыл бұрын
amazing job,man
@Rohit__Patil
5 жыл бұрын
Can we access secret manager across regions example I wana use keyparamer in one region to another
@philiphaslam8501
3 жыл бұрын
Thanks so much!
@technikindia6669
3 жыл бұрын
How can i limit access to aws secrets manager for the iam users.
@jozejerse6777
3 жыл бұрын
error: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
@vasudeva1408
6 жыл бұрын
Good one!
@nileshbhujbal7489
3 жыл бұрын
watch on 1.25x speed
@vekien
5 жыл бұрын
This doesn't work unless you have a lot setup existing, you will run into may VPC issues...
Пікірлер: 31