Re: IAM permissions adjustment on AWS
On Sun, Sep 03, 2017 at 11:34:30PM +0200, Thomas Goirand wrote: > BTW, how do I generate the @(#*$& image manifest? Uploading an image to > amazon is such a pain ... :/ The manifest is created by ec2-bundle-vol. However, it sounds like you're trying to generate what Amazon calls an "instance store backed AMI", which probably isn't what you want. We don't even publish such AMIs for the semi-official stretch cloud images. I suspect that that's why you're having credential issues; you're making API calls that aren't usually called by the ImageBuilders group members. Instead create an EBS-backed volume, which uses the network-attached EBS storage as the root volume. In that case, the steps are: dd your raw image to an EBS volume Snapshot the EBS volume Register the snapshot as an AMI I use the script at [1] when generating the semi-official AWS images. The only required parameters to it are a volume ID. It assumes that you've already generated the raw image and written it to the volume with dd. The only API calls are CreateSnapshot[2] and RegisterImage[3] 1. https://anonscm.debian.org/cgit/cloud/fai-cloud-images.git/tree/volume-to-ami.sh 2. https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSnapshot.html 3. https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RegisterImage.html signature.asc Description: PGP signature
Re: IAM permissions adjustment on AWS
On 08/10/2017 09:28 AM, kuLa wrote: > Hi All, > > 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 tried to get the OpenStack image up on Amazon, and then gave up after 3 rounds of: - "it doesn't work, I don't have enough credentials" - "Here you are, I gave you more, it should work now" So yes, definitively, I'd like to have full access to the account. BTW, how do I generate the @(#*$& image manifest? Uploading an image to amazon is such a pain ... :/ Cheers, Thomas Goirand (zigo)
Re: IAM permissions adjustment on AWS
I just enabled almost full RO permissions for all DDs on Debian AWS account, it's a hand crafted policy to accommodate concerns James presented. I tested it as much as I could but if there is something what ppl think should be changed pls let me know. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: IAM permissions adjustment on AWS
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": [
"AIDAAdminStaffer1",
"AIDAAdminStaffer2",
"AIDAAdminStaffer3"
]
}
}
}
]
}
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
Re: IAM permissions adjustment on AWS
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. Yes please. The current restrictions are very difficult to work with. Broader RO access is a good start. Not only RO permissions need to be updated. I recently replaced my MFA device and found that I don't even have permission to update my IAM role's MFA settings. (Do I even have permission to change my own password? I haven't tried yet.) noah signature.asc Description: PGP signature
Re: IAM permissions adjustment on AWS
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
>
Re: IAM permissions adjustment on AWS
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 -- If a man had a child who'd gone anti-social, killed perhaps, he'd still tend to protect that child. -- McCoy, "The Ultimate Computer", stardate 4731.3
IAM permissions adjustment on AWS
Hi All, 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? Also it was mentioned on DSA BoF on Debconf17 that DSA would like to integrate our LDAP with the accounts on the public clouds which offer such integration. There is more into this subject then just simple integration (there was an idea of delegation of user management on those clouds to the Cloud Team, etc.). It'll need more conversations but I'm just highlighting that such ideas are popping up and I think this is a good idea as well. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
