Secure deployments

The Neptune DXP implements a transfer mechanism akin to a continuous integration pipeline that allows the propagation of artefacts between Neptune DXP runtimes. The intended use is to enable developers to package their deliverables (database tables, scripts, apps, APIs) and allow for the coordinated transfer between their DevOps environments.

Examples of such pipelines are:

  • Traditional Development → Test → Production

  • Web Centric Development → Test → Staging → Production

  • Granular Development → Integration → Performance Testing → Quality → Staging → Production

secure deployments

Regardless, of the approach Neptune DXP implements the following security measures to ensure that only authorised transfers are made:

  • Environment Discovery & Authentication

  • Propagation Routes

  • Multistep Approval Mechanism

  • Access Level Control

Environment discovery and authentication

Environment discovery follows the principle described in the Neptune DXP Microservices Discovery section.

In this case each target system, e.g. Test, must be discovered by the source system, e.g. Development, to enable the transfer of packages between the two, e.g. Development à to Test.

It is recommended that a generic user is setup for each target environment. For example, let’s consider a route to propagate packages from a Test to a Staging environment. In the Staging environment a generic local user, e.g. package_propagation, may be setup with enough access to create/edit Neptune DXP artefacts (e.g. tables, APIs, apps, users). In the Test environment you must then discover the Staging environment and reference the generic user as the authentication account to sign in during the transfer.

Propagation routes

The DevOps team has flexibility on how to approach the propagation of artefacts by creating propagation routes. For example, in a traditional stack the propagation routes could be structured either as:

  • Development → Test → Production

  • Development → Test and when satisfied it works well Development → Production

For Web centric stack:

  • Development → Test → Production, or

  • Development → Test and when satisfied it works well, Development → Staging → Production

Finally, for a Granular stack multiple routes could be configured:

  • Development → Integration

  • Development → Performance Testing

  • Development → Quality

  • Development → Staging → Production

Multistep approval mechanism

Whatever the preference is Neptune DXP applies an optional approval mechanism to the propagation of packages between environments. Three distinct approaches a possible:

  • 1-Step Transfer upon Request

  • 2-Step Request a Transfer à Transfer only upon Approval

  • 3-Step Request a Transfer à Approve Transfer à  Transfer only after an explicit Transfer action is performed

A 3-step process ensure maximum segregation of duties. An example of this approach can be seen below demonstrating the release process by a DevOps team:

secure deployment2

In this example there is complete segregation of duties whereby in:

  • Step-1|DEV the Developer requests the transfer of a package containing all the artefacts to be propagated. In this case a traditional route of Development à Test à Production is chosen.

  • Step-2|DEV after successfully testing the service REST API the Service Owner approves the transfer request for release to the Test environment.

  • Step-3|DEV the Release Manager can then execute the package transfer to the Test environment.

  • Step-2|TST after successfully testing the service the Service Owner approves the transfer request for release to Production .

  • Step-3|TEST the Release Manager can then execute the package transfer to the Production environment

Access level control

The 3-step control mechanism supports email-based workflows and ensures that only approved developments are released to Test and Production. It can be implemented by awarding access to create, approve and transfer packages deployments using Neptune DXP’s role-based access level control function. For the above example the following access to function should be awarded.

secure deployment3