This snippet might be of use. This is what I use on my general
'all-users' group, to keep any users not specified out of my s3
ops bucket with some private keys in it. You specify the blessed
users by IAM user ID, and everyone else is denied. I assume you
could use a similar pattern on other services, though obviously
you'd need to test it out. I combine this with my MFA policy, so
it's applied to all meatspace users 'by default'.
WIth this snippet, I can give a user 'global read-only' to our s3
buckets and still block them from thse buckets. The only downside
is that when a privileged user leaves, you have to remember to
remove the ID (though if you're disabling their user anyway,
that's not much of an issue...).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::my-ops-private-bucket",
"arn:aws:s3:::my-ops-private-bucket/*",
"arn:aws:s3:::my-ops-backups-bucket",
"arn:aws:s3:::my-ops-backups-bucket/*"
],
"Condition": {
"StringNotLike": {
"aws:userId": [
"AIDAxxxxAdminStaffer1",
"AIDAxxxxAdminStaffer2",
"AIDAxxxxAdminStaffer3"
]
}
}
}
]
}
On 11/08/17 00:28, James Bromberger
wrote:
The only down side of this would be any secrets stored in any
SSM Parameter Store locations, but at this point in time I don't
think three are any; historically, people would store secrets
into S3 buckets (probably client-side encrypted, definitely
server side encrypted). These secrets could be locked down to
being accessible to only specific IP ranges, and now to specific
VPCs (see VPC Endpoints, specifically S3 Endpoints). Again, I
don't think we're doing that.
I was trying a few years ago to have SAML federation, but no
one seemed interested. Hence we have local users, and we've
enforced MFA for all.
You'll find there are "Managed Policies' for "read-only", which
are updated as a managed service to reflect read-only as new
permissions and services are added. Note that any DENY policies
win, so a combination of a managed Read Only everything, with
DENY on SSM ParameterStore GetParameters [1] is probably enough.
Not that for IAM itself, you would be able to list API access
key IDs, but never the Access key secrets (These are never
re-issued).
I wouldn't go as far as making this visible to people outside
of DDs.
[1]
{
"Effect": "Deny",
"Action": [ "ssm:GetParameters" ],
"Resource": "arn:aws:ssm:*:DIGITSHERE:parameter/*
"
}
On 10/08/2017 4:44 PM, Bastian Blank
wrote:
Hi
On Thu, Aug 10, 2017 at 08:28:44AM +0100, kuLa wrote:
I'm recently fiddling a lot with permissions on the Debian AWS account and it's
been pointed to me that it's worth considering updating IAM settings a bit.
Having above in mind and that DDs are already trusted enough :-) I'm thinking
about giving a full RO to all DDs which are having access to the AWS account.
What are the people thoughts about this?
I was the one bringing this up. In the beginning I just wanted to see
what real world AWS IAM policies look like and maybe learn a little
about that permission system. This would also enable me to provide
complete patches if modifications are necessary.
I started with trying to access this information using the web interface
and every time a new required permission kept popping up. The current
workflow of granting read permissions one by one does not really scale.
So I asked the question if there are informations and services inside
this account that are so secret that fellow DD would be not allowed to
read them.
Regards,
Bastian