These are chat archives for aws/aws-cli

Jun 2018
Johan Smits
Jun 18 07:23
How can I configure a AWS EB with a application lb and IPv6?
I can't find the correct attributes to set though the cli.
Jun 18 15:00

@angrychimp Thanks for replying! I think the crux of it is authenticating for "least privilege".

As an example, I have a pipeline that runs on-prem from which I need to deploy a lambda. I want to use a least privilege role that only has access to create/update that lambda (or, at least some measure of least privilege).

I have created this pipeline currently with a manual gate for a User to to supply STS keys, but am working towards full automation of acquiring AWS keys to do the code push to s3 and then passing those AWS Keys to TF to do the actual provisioning of the lambda (I wouldn't want to give our CI server keys with full access to AWS accounts)
I have also created an AWS support ticket when I posted here where the support person remarked that utilizing STS would be the best option and to use a SAML assertion for authentication (but, they said acquiring the SAML assertion response is outside their purview, understandably).

But, automating this authentication step is where I'm at. I'm exploring methods for doing this, or I'm going back to the security team and submitting to them that "we don't seem to gain much by storing a "SAML assertion" instead of IAM User keys".

Randall Kahler
Jun 18 20:31

@bogeylnj There has to be trust at some point along the chain, right? If you're looking for actual pipeline automation, I see there being two options. If you want to use external authentication you could use Directory Service to tie an external user (such as an Active Directory service account) to a role, which in turn could allow for STS. But then you have to figure out how to allow your pipeline resources to authenticate with AD (again, as an example), so you still have credentials hard coded somewhere.

In my opinion the safest thing to do is create an automation IAM user with limited access to what you need - S3, Lambda, etc. - and really restrict access to the resources it needs to manage. You can use ARN conditions to make sure you're only touching relevant resources.

You have to hard-code the IAM API key/secret into your pipeline, but at least it can only do exactly what you want it to do. You can use CloudTrail to audit activity and ensure no one is using your pipeline incorrectly. Then just make sure you control access to where ever those keys are stored.

Jun 18 21:00

I completely agree with your first sentence and IAM User recommendation; but I am not savvy enough at this point to confront the security requirements. (Thanks again for your replies - very helpful)

Our AWS Console access is being controlled via Federated Identities and Conditional Policies OktaMFA>STS>IAMRoleWithSpecificResourcesAndConditions. So, everything you describe makes sense.

When I question the security requirement, I think persistent keys will be one of the cons they present with IAM Users. But, this is something that I want to clarify more and more, lately. And, your suggestion supports that.

Some concerns I see are:

  • a need to fully define "least" privilege - does it need to be: byAccount, byTeam, byFunction, etc.
  • the more granular the privilege definition, the more IAM Users that will need to be created and thus, managed. (I assume we will need to rotate keys every so often, control/audit usage, retire unused Users, revoke unused access, etc, etc)
  • citations :) I have a good level of trust with the security team, but I may need some references. Any good resources you have come across/bookmarked that discuss this?

In your experience, are IAM Users used predominantly or are others attempting to avoid them? Most things I find just talk about IAM Users with required access (which in the case of a CI/CD server might be AdministratorAccess).