Deleting a S3 bucket
Today we were cleaning a lot of stuff on our aws account.
You cannot delete a bucket if it’s not empty. So I executed
s3cmd del —recursive —force s3://bucket-name
42 minutes ago.. and still processing it..
AWS IAM Policy: give access to one bucket
Today I had to create a new user in our S3 account and to give him all permissions to just one bucket.
As you can see in our S3 file-manager implementation ( https://github.com/Mashape/file-manager ) I use these two lines to load credentials from a properties file and to connect to the S3 bucket
s3Service = new RestS3Service(awsCredentials);
bucket = s3Service.getBucket(properties.getProperty("s3.bucket"));
The second lines throws an exception if you don’t give s3:ListAllMyBuckets permission to that user. So the final policy I used is this:
{
"Statement": [
{
"Action": [
"s3:ListAllMyBuckets"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::*"
},
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::bucket",
"arn:aws:s3:::bucket/*"
]
}
]
}
Obviously you can avoid the “Action”: “s3:*” part and put just a list of actions you want to allow..
S3 FILEMANAGER
I will republish here my blog post on mashape’s official blog regarding a software I’ve released today
——
Since the beginning we added the possibility to upload a logo to visually identify you and your API. To add this simple feature, from a code point of view, we designed an interface defining basic operations on the uploaded images: load, save, move and delete.
The first implementation was simple and fast to deliver: an abstraction of the local filesystem.
This is fine during the development phase, on our laptops, but obviously, you can’t scale with this solution: every server would have, locally, his own copy of the files.
So I’ve developed a new implementation, S3FileManager (based on he S3 library provided by http://www.jets3t.org ) to store data directly on the awesome Amazon service that we are already using for our static web part (css/images/javascripts).
We haven’t changed a single line of code on our website, except for a configuration file (filemanager.properties). To achieve this goal (and to allow us to change again, in case) this is our design (that can be improved):
Singleton design pattern on FileManagerFactory, with a single static instance that creates an instance of FileManager based on the class name found in a text file (a Properties configuration file).
In this way when we create different Tomcat instances, each of them will have a static FileManagerFactory to access to the same storage.
This simple library fits in our project, in our needs, so it’s not the best fit in every case. But it can be useful for other fellow developer, so here it is: https://github.com/Mashaper/file-manager
For example in other scenarios woule be better a dependency injection pattern instead of a singleton or maybe to avoid the fallback to the default filename ”filemanager.properties” when a getInstance() is called.
Just in case…fork it
