您可以定义实施后操作,以便控制您的用户可对部署及其组件资源进行哪些更改。通过创建全部或部分用户可在部署上运行的允许操作列表,可以确保用户无法进行任何具有破坏性或成本高昂的更改。与实施后操作策略相关的用例介绍了此过程。
授权用户运行实施后操作时,您需要选择他们可以运行的各个操作。您要创建的是包含列表,而不是排除列表。
实施后操作策略何时生效?
- 如果未定义任何实施后操作策略,则不会应用任何监管,并且所有用户都有权访问所有操作。在开始之初不应用任何监管,可以确保您和您的用户无需了解实施后操作策略,即可在 Service Broker 和 Cloud Assembly 中执行实施后操作。
- 在您确定可以控制哪些用户有权访问哪些操作后,可以采用单个实施后操作策略的形式添加监管。当第一个策略生效后,将对 Service Broker 和 Cloud Assembly 中的所有用户执行实施后操作策略。因此,只有符合第一个策略的用户才能运行选定的操作。其他所有用户均排除在外。其他用户之所以排除在外,是因为操作策略包括可信用户。通过排除其他所有用户,您能够创建与您的监管目标相匹配的策略。
- 要授权其他用户,必须创建可授权他们运行所选操作的策略。
项目中的部署共享会影响配置实施后操作授权的方式。如果未将项目设置为共享,则只有请求用户才能查看部署。如果项目共享部署,则项目的所有成员都可以查看部署,并可根据实施后操作策略运行他们有权运行的任何操作。部署共享在项目中进行配置。选择用户选项卡。
,然后选择项目并单击创建策略时,用于定义实施后操作策略的方式必须考虑到共享状态。
要关注何时应用实施后操作策略,可以配置范围、角色和条件。这些配置控制了策略将应用到哪些部署以及在实施策略后谁可以运行操作。
- 策略应用到哪些部署。
- 范围确定了将策略应用到组织还是项目级别的部署。
- 条件可将策略范围缩小到部署的特定方面。
- 哪些用户可以在这些部署上运行哪些操作。
- 角色授权所选角色的成员在选定的范围和条件内运行所选操作。角色可以是项目管理员、项目成员或指定的自定义角色。
当用户尝试使用部署或组件资源上的“操作”菜单管理部署时,将执行实施后操作策略。
此用例假设在项目中启用了部署共享,说明了实施后操作策略的集合。
在查看实施后操作策略用例时,还必须选择操作。您必须选择支持云帐户的操作。
- 操作是特定于云的。当您授权用户进行更改时,请考虑这些授权用户部署到哪些云帐户,并确保您选择操作的所有特定于云的版本。例如,添加 Cloud.AWS.EC2.Instance.Resize、Cloud.GCP.Machine.Resize 和 Cloud.Azure.Machine.Resize 可授权用户调整这些计算机的大小。
- 存在 Cloud.Machine.Resize 等云平台无关的操作,以应对载入或迁移过程无法识别计算机类型时的资源。如果您授权用户运行云平台无关的操作,则表明未授权他们运行将对已部署资源进行更改的云特定操作。不可知操作可能会显示在操作菜单中,但运行这些操作不起作用。应避免授权运行不可知操作,而只授权云特定操作,以确保各种云平台的用户可以执行操作。
前提条件
- 有关可能操作的列表,请参见可以对 Service Broker 部署运行哪些操作。
- 有关构建部署条件的详细信息,请参见如何在 Service Broker 策略中配置部署条件。
- 在实施后操作策略 4 中使用自定义角色。创建部署故障排除人员角色,但具有自定义部署故障排除角色中的管理部署角色时,不会按项目限制成员。管理部署角色允许被分配用户查看所有部署并运行所有操作。如果部署故障排除角色不包括管理部署,则被分配用户将根据其项目成员资格查看部署。有关自定义角色的详细信息,请参见自定义角色用例。
过程
下一步做什么
- 有关如何处理和实施策略的更多示例,请参见如何处理 Service Broker策略。
- 配置与您的组织和项目相关的策略。