Friendly configuration

[JimMadge]

How can we improve the user-facing configuration file so that,

• We maintain our default set of security tiers
• We make the process for overriding the tier-related settings clear
• There is a distinction between these inherited or overwritten settings and others (such as subscription id's)

Currently there is an overrides section, but it requires knowledge of the structure of the full, internal configuration.

[JimMadge]

Here is a potential (JSON) structure,

{
    "base": "tier2",
    "custom": {
        "package_mirrors": "Nexus",
        "internet_outbound": true,
        "internet_inbound": false,
        "remote_connections": "RDP",
        "copy_paste": true
    },
    "common": {
            "shmId": "testa",
            "subscriptionName": "Turing SRE - Sandbox (SHM Test A)",
            "ipPrefix": "10.151.0",
    },
    "overrides": {}
}

• base: Inherent security settings from a pre-defined set (based on tiers).
• custom: Override security settings inherited in base, with friendly names.
• common: Things you will likely always define, not specified by the tier i.e. subscription names.
• overrides: Place to override any setting using it's full configuration path. Likely useful for debugging but shouldn't be necessary or encouraged in production.

The definitions of each base can be defined elsewhere. When parsing the configuration the base configuration will be loaded first, then merged with items in custom.