On Fri, Mar 4, 2016 at 8:25 PM, Kapil Thangavelu <[email protected]> wrote:
> > > On Fri, Mar 4, 2016 at 7:27 PM, Mark Shuttleworth <[email protected]> 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
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
