Closed ChaosInTheCRD closed 2 weeks ago
To give an example, let's say I want to utilise insecureSkipVerify
when connecting to the AWS KMS API:
witness verify --verifier-kms-ref=awskms:///arn:aws:kms:us-east-1:... --verifier-kms-aws-remote-verify=true --policy=./policy-signed.json
In this scenario, policy-signed.json
will have its dsse envelope verified using remote kms verification against the KMS key awskms:///arn:aws:kms:us-east-1:...
and with insecureSkipVerify=true
in the TLS config as one would expect.
However, let's say that the contents of the policy dsse envelope looks something like:
"name": "test",
"attestations": [
{
"type": "https://witness.dev/attestations/command-run/v0.1",
...
],
"functionaries": [
{
"type": "publickey",
"publickeyid": "awskms:///arn:aws:kms:us-east-2:..."
}
]
}
},
"publickeys": {
"awskms:///arn:aws:kms:us-east-2:...": {
"keyid": "awskms:///arn:aws:kms:us-east-2:..."
}
}
}
in the functionaries
field, there is one functionary that is expected to have signed any Witness collections from the test
step.
During the policy verification flow, Witness will (naturally) make another network call to remotely verify the signature of any witness collection found for this step against the KMS key defined for the functionary (awskms:///arn:aws:kms:us-east-2:...
). In this scenario, insecureSkipVerify=true
will not be inherited from the --verifier-kms-aws-remote-verify=true
flag call from the CLI.
This needs to be fixed so that any configuration of the KMS verifier set by CLI flags is inherited when verifying attestation signatures during the policy verification flow.
One way to work around this issue for now is to define the public key in a base64
encoded form in your policy (this is outlined in the documentation). This will also mean that any verifier of the policy will not need to be able to access the KMS key API endpoint, which could even be more optimal for certain users.
At this current moment, KMS verifier flags only apply to the KMS key reference that you supply for verifying the policy signature. When the policy is then read by Witness and used to verify attestation signatures found against the relevant subjects, these flags are ignored. This needs to be fixed as it leads to a confusing experience for the user.