Fwd: AWS Cross Account Roles

[Kapil Thangavelu]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160304/53f8777f/attachment.html>