Proper authorization of services onboarded for deployment.

Context:

The installer platform for services in a cloud, builds them out one after another and adds permissions required for those services so that they are ready. One of the most common permissions granted are those for deployment and storage. As the permissions are granted and the service enabled, an approval request is generated to allow the Service Admin for those services to register the new deployment of their service instance. This addition is then blessed with the help of a Security configuration dashboard to allow the new instance to be recognized, discovered, and used. This article investigates the work items needed to help with automation so that the deployment can scale to all the services.

Requirement:

The tasks begin with a script to add permissions via role assignments where pre-existing roles are defined to secure new instances so that they may proceed with deployment and storage tasks. In addition to the role-based access controls, whitelisting of appropriate folders might be required from the operational side to permit authorized services selectively.

The whitelists and the role-based assignments might both be necessary since they complement each other in the current state of deployment logic and only the operator can take steps to permit service on a case-by-case basis. Usually new regions onboard services but the operator might decide to allow one to work until another one is ready, so whitelisting provides that granularity.

The action items are listed as follows:

1.      Add the storage permission to the instance via role-based assignment.

2.      Add the deployment permission to the instance via role-based assignment.

3.      Whitelist the new instance in the root folders.

4.      Generate an approval request for the service administration.

Even with the approval service integration, it might require manual operation to complete the approval but the request for the approval can now be automated. If a link is generated that can automatically allow the deployment to proceed with the click of the link, it must have sufficient and irrefutable proof that it was indeed issued by the sender. A JWT token might be helpful in this regard.

Observations:

The following are not in scope for this automation proposal:

1.      Any telemetry associated with those that use the current automation

2.      Any telemetry associated with those that will use the proposed automation proposal.

3.      A mechanism to pass the identifier for the new instance to the platform that drives the buildout of services.

4.      Changes to individual buildouts for deployment of services.

Tradeoffs:

This change is a suitable candidate for taking it on the platform side because it is not specific to any one buildout. The other option is to have this whitelist+role-assignment+approval request logic to be taken on the service buildout side but that will only be on a participation basis. Without the telemetry or enforcement mechanisms, it's hard to say whether this will be beneficial and cost-effective. Also, it is possible to one-point maintenance on the platform side.

Conclusion:

This change can be made by taking the mentioned work items on the platform side with the addition of a workflow or sub-workflows for whitelist+role-assignment+approval request raising steps.