Extending the Framework

Extending the framework to custom VPCs, security groups, NACLs, and routing tables is straightforward, because the central mechanism for populating Terraform templates is already in place. New JSON databases could also be added at the back end to support extensions to the framework.

Currently, DevOps Orchestration Platform is a console application that runs a web server, but on an individual user's Debian/Ubuntu/Mint desktop PC – partly for security and partly because the product requires the backing of a bigger open source community with the resources necessary to turn it into a fully networked multiuser or software-as-a-service (SaaS) platform. In any event, the current console-based web server application provides a flexible proof of concept and foundation on which to extend the framework.

Some ideas on how to evolve the framework into a full SaaS platform with role-based access control (RBAC) to a central web server include:

• Add login session and session cookie capability; Golang open source libraries already exist that can facilitate this function.
• Extend the back-end filesystem to include user-ID-specific paths and configuration files.
• Make the Terraform state files user specific, with each user-specific Terraform script and Terraform state file stored at a user-specific filesystem path.
• Use a central database (e.g., Apache Cassandra or Postgres), HashiCorp Vault [7], or a combination of data storage to contain user-specific passwords and keys.
• Control AWS and Google Cloud access permissions by providing users with permission-specific AWS/GCP API keys.
• Store TLS certificates centrally with HashiCorp Vault within a deployed subnet instead of with the existing scheme, which generates private TLS certificates (e.g., for Docker, Nexus 3).