Signed specs

[danj-replicated]

Describe the rationale for the suggested feature.

With the addition of updatable or online specs, it would be nice to have a way for the user of the spec to validate that the team that wrote the spec are the same people providing the remote "updated" version.

Describe the feature

In theory an attacker could MiTM or spoof the response for a spec, and provide a crafted troubleshoot spec with malicious run-pods or host-collectors.

Signed specs would enable us to provide a warning to the user that what they're running might not be from the same place that they got their original spec.

In principle we could use something like pgp or one of the plethora of code-signing tools to create an optional signing workflow for specs to give end-users greater confidence in the remote specs.

[xavpaice]

can you give an example of how that might work in practice? Do we supply 'accepted' signing keys or some such in the original spec, and only specs downloaded that are signed by that key are accepted?

Is there a significantly increased risk with the URL addition, over and above just using the URL on the CLI like we were able to before?

Do you envisage this feature extending to the CLI when we supply a url for the spec (e.g. have some built in keys, or a CLI switch to supply them)?

[danj-replicated]

so my thought around usability was that a spec maintainer could provide a public key (or similar), and the user running troubleshoot could specify the public key with a flag so troubleshoot could validate the signature on the spec.

adding self-links to specs doesn't necessarily increase the potential risk but it does create a somewhat masked attack vector. not in any technical sense, but it creates an extra step to verify what's actually going to be run against your cluster that not all users will check.

the base CLI without self-linked specs would benefit from signed specs too.

[chris-sanders]

I'm concerned that a UX that requires a user to download and provide a key will not be utilized by users. While technically it's more secure, if people aren't using it we aren't providing value. That also means anyone importing and using troubleshoot as a library has to find a way to pass this information around as well. While that's probably the only option if you're just providing a URL from the CLI. I'm actually more concerned about this with the 'online' updates where the user may not be aware that a URI was used to update a spec. Users can always download and review the spec locally if they are worried about a a URL when run from the command line.

I would hope there's an option to use a signature on the spec so that the end user doesn't have to do/change anything. If a URI field is found, the signatures on the specs are compared and the update only used if the signatures match or the user is asked how to proceed.

That's the use case I would think we should target with such a feature. Allowing it to be provided via CLI is fine too, I just think the implementation should be driven to cover verifying automatic updates match the original author and then also allow providing via CLI.

[xavpaice]

could we have, for specs that provide a uri field, another field for the verification:

spec:
  uri: https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/host/cluster-down.yaml
  pubkey: ABBADAD4

This could be used from the CLI and if a spec is stored/supplied by some other mechanism or import.

[banjoh]

could we have, for specs that provide a uri field, another field for the verification:

spec:
  uri: https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/host/cluster-down.yaml
  pubkey: ABBADAD4

This could be used from the CLI and if a spec is stored/supplied by some other mechanism or import.

I like this approach. I'm guessing the spec itself needs to have a new field (metadata perhaps?) section where the signature would be stored.

# Spec to run when a kURL cluster is down and in-cluster specs can't be run
apiVersion: troubleshoot.sh/v1beta2
kind: SupportBundle
metadata:
  name: cluster-down
  signature: <LOOOOONG SIGNATURE STRING>
spec:
  hostCollectors:
    # System Info Collectors
    - blockDevices: {}
    - cpu: {}
    - hostOS: {}
    - hostServices: {}
    - ipv4Interfaces: {}
    - memory: {}
    - time: {}

The signature can be an external file as well passed in as the spec uri, but I find the embedded signature approach cleaner.

[chris-sanders]

I'm not sure what the maximum characters are for a metadata field we should be sure the signature can fit, but I like the idea.