Ingest access legacy migration

[bcmdarroch]

Current Solution

On v1, we had some default policies: one granting all tokens access to ingest endpoints (like /data-collector/v0) and a few others granting all users access to cfgmgmt things (GET client runs, etc)

		constants.IngestWildcardPolicyID: {
			ID:       ids[constants.IngestWildcardPolicyID],
			Subjects: []string{"token:*"},
			Resource: "ingest:*",
			Action:   "*",
			Effect:   "allow",
			Version:  1,
		},

		constants.CfgmgmtStatsWildcardPolicyID: {
			ID:       ids[constants.CfgmgmtStatsWildcardPolicyID],
			Subjects: []string{"user:*"},
			Resource: "cfgmgmt:stats:*",
			Action:   "*",
			Effect:   "allow",
			Version:  1,
		},
		constants.CfgmgmtNodesWildcardPolicyID: {
			ID:       ids[constants.CfgmgmtNodesWildcardPolicyID],
			Subjects: []string{"user:*"},
			Resource: "cfgmgmt:nodes:*",
			Action:   "*",
			Effect:   "allow",
			Version:  1,
		},
		constants.CfgmgmtNodesContainerPolicyID: {
			ID:       ids[constants.CfgmgmtNodesContainerPolicyID],
			Subjects: []string{"user:*"},
			Resource: "cfgmgmt:nodes",
			Action:   "*",
			Effect:   "allow",
			Version:  1,
		},

On v2, the ingest endpoints moved under the infra:* namespace (aka the new name for cfgmgmt). This meant users got access the formerly client-only endpoints when they got infra:* permissions. To minimize security risks, we decided to add a DENY statement so users could not access infra:ingest:* endpoints (like /data-collector/v0)

    {
      "name": "[Legacy] Ingest Access",
      "id": "ingest-access-legacy",
      "type": "CUSTOM",
      "members": [
        "token:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "infra:ingest:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        }
      ],
      "projects": []
    }

{
      "name": "[Legacy] Infrastructure Automation Access",
      "id": "infrastructure-automation-access-legacy",
      "type": "CUSTOM",
      "members": [
        "user:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "infra:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        },
        {
          "effect": "DENY",
          "actions": [
            "infra:ingest:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        }
      ],
      "projects": []
    }

This causes problems however because it blocks admins from using infra:ingest endpoints. Admins should be able to do anything that won't break the system (like deleting themselves)

Option 1

We move https://github.com/chef/automate/blob/master/api/external/ingest/chef.proto and https://github.com/chef/automate/blob/master/components/automate-gateway/api/legacy/legacy.proto endpoints into their own top-level ingest:* namespace. Then the v1 default policies can be migrated to v2 as:

 {
      "name": "[Legacy] Ingest Access",
      "id": "ingest-access-legacy",
      "type": "CUSTOM",
      "members": [
        "token:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "ingest:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        }
      ],
      "projects": []
   }
 {
      "name": "[Legacy] Infrastructure Automation Access",
      "id": "infrastructure-automation-access-legacy",
      "type": "CUSTOM",
      "members": [
        "user:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "infra:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        } 
      ],
      "projects": []
    }

This will take longer and might require some migrations (if customers made new policies with infra:ingest:*, but in the end might represent the ingest actions more accurately.

Option 2

We remove the DENY statement and only grant users access to non infra:ingest:* actions

 {
      "name": "[Legacy] Ingest Access",
      "id": "ingest-access-legacy",
      "type": "CUSTOM",
      "members": [
        "token:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "ingest:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        }
      ],
      "projects": []
   }
 {
      "name": "[Legacy] Infrastructure Automation Access",
      "id": "infrastructure-automation-access-legacy",
      "type": "CUSTOM",
      "members": [
        "user:*"
      ],
      "statements": [
        {
          "effect": "ALLOW",
          "actions": [
            "infra:nodes:*", "infra:servers:*", "infra:serverOrgCookbooks:*", "infra:nodeManagers:*"
          ],
          "role": "",
          "resources": [
            "*"
          ],
          "projects": [
            "*"
          ]
        } 
      ],
      "projects": []
    }

This is the quickest option

[lancewf]

I like option one better because it does not give the user the impression that they can only ingest chef infra data.

[vjeffrey]

+1 on the first option

[bcmdarroch]

Option 1 it is!

[susanev]

this will also require a change to the editor, viewer, project owner, and ingest roles.