【问题标题】:Spinnaker User Authorization and Instance Permission RestrictionsSpinnaker 用户授权和实例权限限制
【发布时间】:2017-10-06 02:52:52
【问题描述】:

我正在尝试使用 Spinnaker 烘焙 AMI 并将其部署到 AWS Auto Scaling Group。问题是,实例需要too many permissions。正如Spinnaker blog post 中所述(即“在当今世界,让工具完全访问您的环境通常被视为不好的做法”),我想知道是否有办法限制 Spinnaker 实例权限,但仍允许用户将他们的应用程序部署到他们自己的集群中,例如如果他们在 AWS 中获得授权。

当然,文档说您可以限制对应用程序的访问,但这是否足够?应用程序 A 的成员能否以某种方式(例如在管道阶段)利用 Spinnaker 的权限调用 AWS API? (因此能够修改应用程序 B 的集群)。假设对 Spinnaker 实例的 SSH 访问已被禁用

【问题讨论】:

    标签: amazon-web-services autoscaling spinnaker least-privilege


    【解决方案1】:

    正确设置授权后,如果应用程序 A 的成员没有权限,他们应该无法修改应用程序 B(请参阅here)。此防护位于 Spinnaker 应用程序级别,而不是云提供商 (EC2) 平台级别。

    Spinnaker 是使用“上帝模式”凭据构建的 - 因此实际上相同的凭据被用于操作应用程序 A 和 B 的云资源。

    【讨论】:

    • 是否有计划从“上帝模式”切换/支持管道执行器的凭据?为了支持我们当前的案例:团队仍然将应用程序部署到单个共享 AWS 账户,我希望能够在单个仪表板中跟踪谁做了哪些更改以及何时对该账户进行了更改,这就是 AWS 的 CloudTrail。我希望能够看到类似“用户 A 修改 ASG X”的内容。我目前的 hack 是在每个开发人员的笔记本电脑上运行 spinnaker
    • 暂时没有,但我们愿意接受建议。问题通常以并非每个云提供商都有 IAM/RBAC 安全模型而告终。没错,理想情况是 Spinnaker 的缓存代理使用只读凭据,并且在适当时使用最终用户凭据。我们必须弄清楚如何从云提供商那里提取(并安全地存储)最终用户凭据。那么我们要问自动触发的流水线有什么作用呢?这是一个棘手的问题,答案不明确。
    猜你喜欢
    • 2015-04-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多