<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 8:25 PM, Kapil Thangavelu <span dir="ltr"><<a href="mailto:kapilt@gmail.com" target="_blank">kapilt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Mar 4, 2016 at 7:27 PM, Mark Shuttleworth <span dir="ltr"><<a href="mailto:mark@ubuntu.com" target="_blank">mark@ubuntu.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 04/03/16 12:17, Kapil Thangavelu wrote:<br>
> They can be refreshed prior to expiration to get equivalent immortality,<br>
> example using pysdk<br>
> <a href="https://gist.github.com/kapilt/ac8e222081f63ba64e93" rel="noreferrer" target="_blank">https://gist.github.com/kapilt/ac8e222081f63ba64e93</a><br>
><br>
> Ideal usage is actually using Iam instance roles as well for instance<br>
> credentials which basically work the same way wrt to refresh intervals. As<br>
> perm credentials on servers violates aws best practices.<br>
<br>
</span>TO test my understanding, is the idea that one might need to provide<br>
actual credentials when deploying a service or creating a model, but<br>
then the system actually keeps a token which it keeps refreshing rather<br>
than keeping the full credential?<br></blockquote><div><br></div><div><br></div></span><div>Not exactly. So permanent user api credentials are just as verboten in some orgs as system/machine credentials.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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]</div><div><br></div><div>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.</div><div><br></div><div>cheers,</div><div>Kapil</div><div><br></div><div>[0] - some additional articles on aws security</div><div> -  <a href="https://99designs.com/tech-blog/blog/2015/10/26/aws-vault/" target="_blank">https://99designs.com/tech-blog/blog/2015/10/26/aws-vault/</a></div><div> -  <a href="https://cloudonaut.io/your-single-aws-account-is-a-serious-risk/" target="_blank">https://cloudonaut.io/your-single-aws-account-is-a-serious-risk/</a></div><div> -  <a href="https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf" target="_blank">https://d0.awsstatic.com/whitepapers/compliance/AWS_CIS_Foundations_Benchmark.pdf</a> </div><div><br></div><div><br></div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">also fwiw this was filed as a feature request/bug a while ago</div><div class="gmail_extra"><a href="https://bugs.launchpad.net/juju-core/+bug/1316602">https://bugs.launchpad.net/juju-core/+bug/1316602</a><br></div><div class="gmail_extra"><br></div></div>