Add the capability to prevent further modifications to entries

[daescha]

There is no way to disable the entry modification via cli once you have registered what you need. This seems like a useful feature to have, so you don't have to worry about attackers registering additional workloads if they gain exec access to the spire-server container.

[MarcosDY]

Seems related with #1842 and #2626

[daescha]

@MarcosDY thanks for linking to the interesting discussion on those issues. I was thinking it would probably be better to split this issue into two parts, one for disabling entry additions/updates, the other for adding initial entries. adding the initial entries would just be part of #2626 I guess, so Ill remove that part of this issue.

e: removed that part.

[MarcosDY]

Thanks @daescha!! we saw your PR, can you provide an example of the entry file?
How about hardcoding entry id to those "static" entries?

[daescha]

@MarcosDY further discussion should probably take place on the PR (or alternatively #2626) since I changed the subject of this issue to be the other part of my initial issue, but Ill respond to what you said here this time at least.

example is same format as the the file passed to spire-server entry create -data:

    {
      "entries": [
        {
          "parent_id": "spiffe://example.com/spire/server",
          "selectors": [
            {
              "type": "k8s_psat",
              "value": "agent_ns:spire-system"
            },
            {
              "type": "k8s_psat",
              "value": "cluster:minikube"
            },
            {
              "type": "k8s_psat",
              "value": "agent_sa:spire-agent"
            }
          ],
          "spiffe_id": "spiffe://example.com/ns/spire-system/sa/spire-agent"
        },
        {
          "parent_id": "spiffe://example.com/ns/spire-system/sa/spire-agent",
          "selectors": [
            {
              "type": "k8s",
              "value": "container-name:envoy-control-plane"
            },
            {
              "type": "k8s",
              "value": "ns:default"
            },
            {
              "type": "k8s",
              "value": "pod-label:app.kubernetes.io/name:gateway"
            },
            {
              "type": "k8s",
              "value": "sa:gateway"
            }
          ],
          "spiffe_id": "spiffe://example.com/ns/default/sa/gateway/gateway"
        },
        {
          "parent_id": "spiffe://example.com/ns/spire-system/sa/spire-agent",
          "selectors": [
            {
              "type": "k8s",
              "value": "container-name:gateway"
            },
            {
              "type": "k8s",
              "value": "ns:default"
            },
            {
              "type": "k8s",
              "value": "pod-label:app.kubernetes.io/name:gateway"
            },
            {
              "type": "k8s",
              "value": "sa:gateway"
            }
          ],
          "spiffe_id": "spiffe://example.com/ns/default/sa/gateway/gateway"
        },
        {
          "parent_id": "spiffe://example.com/ns/spire-system/sa/spire-agent",
          "selectors": [
            {
              "type": "k8s",
              "value": "container-name:firstapp-proxy"
            },
            {
              "type": "k8s",
              "value": "ns:default"
            },
            {
              "type": "k8s",
              "value": "pod-label:app.kubernetes.io/name:firstapp"
            },
            {
              "type": "k8s",
              "value": "sa:firstapp"
            }
          ],
          "spiffe_id": "spiffe://example.com/ns/default/sa/firstapp/firstapp"
        },
        {
          "parent_id": "spiffe://example.com/ns/spire-system/sa/spire-agent",
          "selectors": [
            {
              "type": "k8s",
              "value": "container-name:thirdapp-proxy"
            },
            {
              "type": "k8s",
              "value": "ns:default"
            },
            {
              "type": "k8s",
              "value": "pod-label:app.kubernetes.io/name:thirdapp"
            },
            {
              "type": "k8s",
              "value": "sa:thirdapp"
            }
          ],
          "spiffe_id": "spiffe://example.com/ns/default/sa/thirdapp/thirdapp"
        }
      ]
    }

I imagine if you wanted static IDs you would just put in "id": "2bddeead-8e84-4d35-9845-a3502ce045bd" or whatever you want into the entry file, right? or are you saying we should automatically set a static ID for them, hardcoding it in somehow? If the latter, how would you suggest that work?

I made a fork of helm-charts-hardened that I am using to test, you can see the changes here: spiffe/helm-charts-hardened@main...daescha:helm-charts-hardened:use-defaults

[sorindumitru]

Hi @daescha,

For the entry file we'd want to be able to update and delete the entries by deploying a new version of the file. If we leave the id empty, spire-server will generate a random one for us. This makes it hard to identify which entry we'd have to check to see if it needs updating.

If we mandate that the id is specified for all entries we will be able to identify the entries that have been previously created to try to update them. You'll likely have to first fetch the entry/entries to see if they exist to decide if you need to update or create.

With a defined id we still won't know when to delete the entries. For that we could enforce that the entries have a predefined suffix, such as static/. This way you can look through all of the entries that start with static and figure out which ones are gone from the file and delete them. Since some deployments might already have entries created with static/ in them, we should make that a configurable prefix, with a default of that value.

To allow users to change the prefix, we'd want to have another optional prefix defined which specifies which entries should be cleaned up. For example you'd want to switch from static/ to fixed/ so you now specify the static prefix as fixed/ and the prefix to be cleaned up as static/ so that the old entries don't stay around for a long time.

[sorindumitru]

For the locking the service part of things, could you add some more details about how you are planning to use this? With the current PR it seems like you want to lock the service soon after it starts up, every time it starts up?

We need to discuss this some more before to see what scenarios we want to cover before committing to a specific solution for this.

[daescha]

For the entry file we'd want to be able to update and delete the entries by deploying a new version of the file. If we leave the id empty, spire-server will generate a random one for us. This makes it hard to identify which entry we'd have to check to see if it needs updating.

If we mandate that the id is specified for all entries we will be able to identify the entries that have been previously created to try to update them. You'll likely have to first fetch the entry/entries to see if they exist to decide if you need to update or create.

With a defined id we still won't know when to delete the entries. For that we could enforce that the entries have a predefined suffix, such as static/. This way you can look through all of the entries that start with static and figure out which ones are gone from the file and delete them. Since some deployments might already have entries created with static/ in them, we should make that a configurable prefix, with a default of that value.

To allow users to change the prefix, we'd want to have another optional prefix defined which specifies which entries should be cleaned up. For example you'd want to switch from static/ to fixed/ so you now specify the static prefix as fixed/ and the prefix to be cleaned up as static/ so that the old entries don't stay around for a long time.

Okay, ill work on this. I currently use spire with an in memory sqlite database, so totally did not factor in entries already existing and such scenarios, thanks for pointing that out.

[daescha]

For the locking the service part of things, could you add some more details about how you are planning to use this? With the current PR it seems like you want to lock the service soon after it starts up, every time it starts up?

We need to discuss this some more before to see what scenarios we want to cover before committing to a specific solution for this.

heres my scenario:

1. spin up k8s cluster. add spire server and agent. register a couple entries for use.
2. start the main applications that use spiffe certs to talk to each other. No need to touch spire server or agent again.
3. since there is no more need to add additional entries, or interact with the server, it would seem more secure to 'lock' the servers entry database, to prevent additions and modifications. If some bad actor somehow gets exec access on the spire-server container, they cannot register additional entries with the same url as an existing entry and then 'spoof' (might be using that incorrectly) the certs, so to speak. Additionally, they cannot modify existing entries to have other characteristics, e.g., point to bad pod or something.

@sorindumitru I have a feeling I am making some sort of faulty assumption that makes my scenario either short sighted or irrelevant, but I am not familiar enough with spire to know if that's right. Hoping to get opinions on that.