I am currently curious about if there any risks when using S3 GUI client tool like S3Browser or Cyberduck to explore our S3 file with AWS secret keys.
https://s3browser.com/
https://cyberduck.io/
Can those aws keys will be stolen by the tool?
Both of these services store the keys locally on your host machine.
From experience I know that S3 Browser allows your credentials to be encrypted locally on the disk using a password of your choosing as the decryption key.
Obviously goes without saying but when using any service ensure the following to increase your security:
Regularly rotate your credentials.
Your IAM policies should locked down to the minimum settings you require.
If you're concerned about API calls enabled S3 API calls in CloudTrail
If its a 1 time key, immediately remove it afterwards from both the software and your AWS account.
S3 browser also supports the assuming of a role which allows it to generate temporary credentials.
Nothing is 100% risk free. As a developer who has built one of those s3 browser, this is what I'm doing to mitigate the risk:
the entire code is 100% open source (https://github.com/mickael-kerjean/filestash) so you can audit the code that actually runs
there's a special page from the application that shows the hash of the binary alongside the commit from which this version is built from to enable anyone to see the built they run and verify it as well
I support assume role so you can use short lived credentials
Related
I have an AWS account with full access to DynamoDB.
I am writing an application that uses DynamoDB. I would like to test this application backed by the real DynamoDB (and not any local compatible/mock solution). However, the test application is not as secure a real production-ready application, and there is a real risk that during my tests an attacker may break into the test machine. If my real AWS credentials (needed to write to DynamoDB) are on that machine, they may be stolen and the attacker can basically do anything that I can do on DynamoDB - e.g., create expensive VMs in my account next week and mine for bitcoin.
So I'm looking for an alternative to saving my real AWS credentials (access key id and secret access key) on the test machine.
I read about Amazon's signature algorithm v4, and it turns out that its signature process is actually two-staged: First a "signing key" is calculated from the full credentials and this signing key works only for a single day on a single service - and then this "signing key" is used to sign the individual messages. This suggests that I could calculate the signing key on a secure machine and send it to the test machine - and the test machine will only do the second stage of the signature algorithm, and will only be able to use DynamoDB and only for a single day.
If I could do this, this would solve my problem, but the problem is that I couldn't figure out how I can tell boto3 to only do the second stage of the signing. It seems it always takes the full credentials aws_access_key_id and aws_secret_access_key - and does both stages of the signature. Is there a way to configure it to only do the second stage?
Alternatively, is there a different way in AWS or IAM or something, where someone like me that has credentials can use them to create temporary keys that can be used only for a short amount of time and/or only one specific service?
create temporary keys that can be used only for a short amount of time and/or only one specific service
Yes, that's why AWS STS service exists. Specifically you can use GetSessionToken which:
Returns a set of temporary credentials for an AWS account or IAM user. The credentials consist of an access key ID, a secret access key, and a security token.
You can also create IAM roles, and used STS's AssumeRole for the same thing. Actually using IAM roles for instances is the most preferred way to give temporary permissions for the applications on EC2 instances. This way you don't have to use your own credentials at all.
How in a work environment with different AWS environments say for example develop, staging and production is it best to store the AWS Access Key and Secret Key other than in the appsettings.json files in .Net Core? I know there is Secret Manager but not sure if that is the best way to store these two values. Looking for someone that may have done this specifically for production and how they handled this within their organization. Thanks for any information.
I believe that your application is running outside of AWS and that it needs to make API calls to AWS services, for example SQS. To make those API calls, your application needs AWS credentials.
Here are approaches for authenticating external applications in a machine-to-machine scenario. In your case, your client seems to need to be able to make arbitrary AWS service requests and that means using AWS signature v4 requests, signed using AWS credentials, which are ideally temporary, rotated credentials from STS rather than persistent credentials (such as IAM user credentials).
Typically, you would configure your application with a base set of IAM credentials that allow the application to assume an IAM role. That role itself, rather than the base credentials, would then give your application the permissions it needs to make SQS API calls etc.
The issue you face is how to securely store the base set of credentials. This is a problem that on-premise applications have had since day one, well before the cloud era, and there are various solutions, depending on the technology you're using.
Typically these credentials would be encrypted, not committed to code repos, and populated on the relevant, locked down application servers in some secure fashion. Some potentially useful resources:
Encrypting sections of a configuration file for an ASP.NET application
Use AWS Secrets Manager to store & read passwords in .Net Core apps
Securely store and retrieve sensitive info in .NET Core apps with Azure Key Vault
AWS Secret Manager securely stores your secrets until you retrieve them at runtime. If your going to be running your ASP.NET Core app in AWS, then AWS Secrets Manager is a great option, as it allows you to finely control the permissions associated with the AWS IAM roles running your apps.
Here are some faqs which were given from the AWS for secrets-manager service and which will clear your doubts also.
Here is the article which you can refer to for implementing secure secrets storage for .net core with AWS Secret Manager
So it says on the github documentation here that
AWS Vault is a tool to securely store and access AWS credentials in a
development environment.
AWS Vault stores IAM credentials in your operating system's secure
keystore and then generates temporary credentials from those to expose
to your shell and applications. It's designed to be complementary to
the AWS CLI tools, and is aware of your
But what does this actually mean? As a developer does this mean to create a kind of lock to prevent anyone from using my code without the aws-vault profile? When should I use this technology? I want to know a bit more about it before I use it.
It actually doesn't have anything related to development.
While working with Amazon managed services we can take advantage of IAM roles but that doesn't work when you're doing it from our local environment or from some other Cloud VM like accessing a S3 bucket. It comes handy when you're doing a lot of work with AWS CLI or even writing terraform for your environment. It is just for a precaution so we don't expose or IAM credentials to external world (you will receive an abuse notification from Amazon whenever your keys are compromised). There are many other ways to make sure your keys don't get compromised like before pushing your code to a version control use git-secrets to make sure you don't push any sensitive information.
I'm currently using AWS S3 credentials inside my application's code in a file ignored by git, but every developer has that file so it can work with images.
I want to hide those credentials from the developers, but still have the ability to use S3 in the development environment.
What are the best practices on that?
Should I replace S3 usage to local files in the development environment?
Give each of your developers IAM accounts with their own API keys, set your application to read the API keys from environment variables rather than from a config file. When the code runs on EC2 instances, use IAM roles so that you don't need to use API keys at all. If you're using AWS SDKs it will use role credentials by default.
I have data from multiple users inside a single S3 account. My desktop app has an authentication system which let the app know who the user is and which folder to access on S3. but the desktop app has the access code to the whole S3 folder.
somebody told me this is not secure since a hacker could break the request from the app to the S3 and use the credentials to download all the data.
Is this true? and if so how can I avoid it? (he said I need to a client server in the AWS cloud but this isn't clear to me... )
btw. I am using Boto python library to access S3.
thanks
I just found this:
Don't store your AWS secret key in the app. A determined hacker would be able to find it eventially. One idea is that you have a web service hosted somewhere whose sole purpose is to sign the client's S3 requests using the secret key, those requests are then relayed to the S3 service. Therefore you get your users to authenticate agaist your web service using credentials that you control. To re-iterate: the clients talk directly to S3, but get their requests "rubber-stamped"/approved by you.
I don't see S3 necessarily as a flat structure - if you use filesystem notation "folder/subfolder/file.ext" for the keys.
Vanity URLs are supported by S3 see http://docs.amazonwebservices.com/AmazonS3/2006-03-01/VirtualHosting.html - basically the URL "http://s3.amazonaws.com/mybucket/myfile.ext" becomes "http://mybucket.s3.amazonaws.com/myfile.ext" and you can then setup a CNAME in your DNS that maps "www.myname.com" to "mybucket.s3.amazonaws.com" which results in "http://www.myname.com/myfile.ext"
Perfect timing! AWS just announced a feature yesterday that's likely to help you here: Variables in IAM policies.
What you would do is create an IAM account for each of your users. This will allow you to have a separate access key and secret key for each user. Then you would assign a policy to your bucket that restricts access to a portion of the bucket, based on username. (The example that I linked to above has good example of this use case).