Fwd: AWS Cross Account Roles

[Kapil Thangavelu]

On Fri, Mar 4, 2016 at 8:25 PM, Kapil Thangavelu <kapilt at gmail.com> wrote:

>
>
> On Fri, Mar 4, 2016 at 7:27 PM, Mark Shuttleworth <mark at ubuntu.com> wrote:
>
>> On 04/03/16 12:17, Kapil Thangavelu wrote:
>> > They can be refreshed prior to expiration to get equivalent immortality,
>> > example using pysdk
>> > https://gist.github.com/kapilt/ac8e222081f63ba64e93
>> >
>> > Ideal usage is actually using Iam instance roles as well for instance
>> > credentials which basically work the same way wrt to refresh intervals.
>> As
>> > perm credentials on servers violates aws best practices.
>>
>> TO test my understanding, is the idea that one might need to provide
>> actual credentials when deploying a service or creating a model, but
>> then the system actually keeps a token which it keeps refreshing rather
>> than keeping the full credential?
>>
>
>
> Not exactly. So permanent user api credentials are just as verboten in
> some orgs as system/machine credentials.
>
> Let's take a typical enterprise on aws for example, and granted there is
> some variation here but afaict this is pretty standard [0], they'll auth
> via federated auth integration (saml) to aws for console access. For user
> api access, its on the basis of temporary credentials from sso login. These
> typically gets written out in a standard format (~/.aws/credentials) and
> config (~/.aws/config) readable across sdks and can be referenced via a
> profile name as short cut to specifying api key, secret, and session token.
> If the user is then provisioning a server that wants api access, they'll
> select an iam instance role for the server, instead of using their personal
> time limited credentials for an application.
>
> Fwiw, given the wide variety of software that interacts with aws, most
> enterprise companies have an exception process for creating long standing
> keys for given apps, albeit with credentials rotation.
>
> The other use case this comes up in per the original email, is with cross
> account usage which is fairly common either between orgs or within orgs
> that have multiple accounts. In that scenario the user or app uses their
> credentials to sts role assume (ie get temporary credentials) into a
> different account they've been given access to. In some circles that's a
> best practice even for non enterprise to guard the primary account (aka
> bastion accounts) per second article in [0]
>
> alot of the legwork for this comes for free with standard sdks including
> the golang one which juju doesn't use. albeit almost all of those are
> autogen'd/dynamically constructed beyond the core for actual services apis
> from json file descriptors.
>
> cheers,
> Kapil
>
> [0] - some additional articles on aws security
>  -  https://99designs.com/tech-blog/blog/2015/10/26/aws-vault/
>  -  https://cloudonaut.io/your-single-aws-account-is-a-serious-risk/
>  -
> https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf
>
>
>
>
also fwiw this was filed as a feature request/bug a while ago
https://bugs.launchpad.net/juju-core/+bug/1316602
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160304/871f9c14/attachment.html>