kushaldas/qubes_ansible

qubes_ansible IDE for enterprise DevOps?

Opened this issue · 0 comments

harmonicalchemy commented

I would like to explore the idea of extending qubes-ansible to enable a Qubes OS computer (laptop etc.) as a developer's source IDE machine. This "Qubes Based Dev Box" will manage both local staging (disposable CentOS LEMP AppVM sandboxes) (PVH or HVM?) and remote (live) VPS LEMP machines running within a remote data center. CentOS is my OS of choice for enterprise projects. (Ubuntu LTS as second choice for other things)

See Attached Doc: Qubes-Ansible-Work-Flow-Process-chart. This provides a visual overview of the discussion below...

The three qubes-ansible issues thus far appear to be general Qubes OS SysAdmin related features, however some discussion witin those issues may be revelavant to this new project, espceially: Discussing the security aspect of Ansible for Qubes OS

I would like to give this DevOps specific qubes-ansible discussion special meaning (for developers) apart from general Qubes OS use cases. The developer community could benifit greatly, especially developers working on new Web 3.0 (or rather Internet 3.0 which was supposed to be Internet 1.0 to some of us old-dogs)

Objectives:

I need to be able to leverage Ansible, Vagrant, VirtualBox, Jenkins, and possibly Docker, etc. to streamline and automate my "private cloud" PubOps, git-server, web3, blockchain, etc. projects... and also be able to author all of that open source within a dedicated Qubes [DevOps] AppVM... My aim is for a Secure DevOps IDE running along side my secure PersonalOps and PubOps using the best compartmentalization schemes available...

It may be entirely possible (and certainly hoped) that Qubes Salt Stack features may provide similar "container" (compartmentalization) management tasks instead of depending on Vagrant, VirtualBox, Docker, etc... That would be a nice chunck of attack-surface to reduce, remove, or improve...

My other objective is to keep all required outside 3rd party hosting infrastructure as thin as possible. In other words: No AWS Share Cropping! I prefer simple commodity based VPS providers like DigitalOcean, or the handful of others that seem to be popping up a lot these days! With a fully automated dispach in place, It does not matter so much who currently hosts the VPS instances... They are disposable too (with obvious minor down-time to: spin-up new VPS & change DNS record if something happened unexpectedly - not planned)...

Current Facts:

Local Dev Machine: Lenovo T480 Laptop running Qubes 4.0+ (latest updates) Fedora 29, Debian 9, Whonix (latest templates egtc.) Several Fedora 29 based templates designed for different purposes: (App VMs Service VMs Dev VMs, etc.). I have not yet tried using disposible VMs for [sys-net] [sys-firewall] etc. But am about to do that next using Ansible Qubes to see how that goes...

[Dom0] Ansible Qubes for General Qubes Management:

  • Ansible Qubes Installed in Dom0 - Success
  • Ansible Qubes Tests on existing Templates and App VMs - Success
  • Ansible Qubes Creation of new VMs - Success
  • Precise granular, trackable, control over all Qubes SysAdmin tasks using a human readable format that is widely used, shared, and reviewed throughout the industry! Fantastic... (will be exploring this much more on-going to best automate my work-load and create some interesting and useful NIDS templates, tools, etc. as well %^)

Current Needs:

[AppVM] Ansible Qubes for Local DevOps building/testing/staging:

See attached PDF: Qubes-Ansible-Work-Flow-Process-chart. for a visual overview of the discussion below...

I would like to add the following features to Qubes Ansible:

  • Run Ansible Qubes from within an AppVM: [devOps] to do limited and isolated DevOps related SysAdmin tasks such as fire up a disposable Qube within its own isolated localhost network for testing web-apps off line. Everything goes "poof" when you are done with test, benchmark, new feature tryout, etc. Would be perfect for dev-testing-branching etc.. Is this possible? And good idea? Security implications?

  • The [DevOps] AppVM shall interface with a subset of the Qubes Salt Stack This will limit the DevOps AppVM from being able to do things when it does not have a "need-to-know" or "need-to-configure" basis on those more general (and dangerous) Qubes SysAdmin kinds of things...

  • Ansible Playbooks Created within [DevOps] VM: will be able to configure, build, and run disposible Qubes AppVMs (for local dev/staging within an isolated disposable localhost network), with a second playbook that deploys the same VM imstance as a hosted VPS Droplet on DigitalOcean, Linode, or any other commodity unmanaged VPS hosting provider. Is this also possible? And good idea? Security Implications?

  • Taking the Two Ideas Above to the Next Step:
    What if you could use Ansible Qubes to create a small isolated "mini private network" between two or more disposable qubes that could only talk to each other via SSH/HTTPS etc. but not be connected to or use the normal Qubes [sys-firewall] --> [sys-net] facility? Shall we call this a Qubes Internal Sandbox Test Network? Is this also possible? And good idea? Security Implications?

This is the general idea... We can go into details later... Lets clarify my initial needs first... Thanks... This Qubes Ansible project is awesome btw!!! I don't need much direction... If you point me in the right direction... I will pick it up and run-run-run... I only need a few cues... I will find the rest in the code (where I like to live) Thanks!

I forked the project in my own Github Account and will be making changes there... The Libre Office Draw source file for the attached diagram will also be committed to my fork... Thank you for all this fantastic work! I look forward to even more possibilities! I am willing to do what ever it takes... This is vitally important for me and many other developers going forward into Web 3.0!