docs(specification): improve Key Management documentation following M…

…D014

When there are only commands in the code block, the `$` sign is not needed

Specification reference: https://github.com/DavidAnson/markdownlint/blob/v0.29.0/doc/md014.md

Resolves: #217

Signed-off-by: 诺墨 <zhangshengxiang@gitee.com>

content/en/key_management/hardware-based-tokens.md

@@ -21,8 +21,8 @@ We recommend using an application provided by your hardware vendor to manage key
 The following exmamples use this image:
 
 ```shell
-$ IMAGE=gcr.io/user-vmtest2/demo
-$ IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd
+IMAGE=gcr.io/user-vmtest2/demo
+IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd
 ```
 
 ## Quick Start
@@ -175,7 +175,7 @@ Tests can be run against a device with the following command.
 **WARNING**: These tests will destroy any keys on your device.
 
 ```shell
-$ go test ./test -tags=resetyubikey,e2e -count=1
+go test ./test -tags=resetyubikey,e2e -count=1
 ```
 
 **WARNING**: These tests will destroy any keys on your device.

content/en/key_management/overview.md

@@ -19,7 +19,7 @@ To generate keys using a KMS provider, you can use the `cosign generate-key-pair
 For example:
 
 ```shell
-$ cosign generate-key-pair --kms <some provider>://<some key>
+cosign generate-key-pair --kms <some provider>://<some key>
 ```
 
 The public key can be retrieved with:
@@ -37,8 +37,8 @@ jnVtSyKZxNzBfNMLLtVxdu8q+AigrGCS2KPmejda9bICTcHQCRUrD5OLGQ==
 For the following examples, we have:
 
 ```shell
-$ IMAGE=gcr.io/user/demo
-$ IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd
+IMAGE=gcr.io/user/demo
+IMAGE_DIGEST=$IMAGE@sha256:410a07f17151ffffb513f942a01748dfdb921de915ea6427d61d60b0357c1dcd
 ```
 
 To sign and verify using a key managed by a KMS provider, you can pass a provider-specific URI to the `--key` command:
@@ -61,8 +61,8 @@ The following checks were performed on each of these signatures:
 You can also export the public key and verify against that file:
 
 ```shell
-$ cosign public-key --key <some provider>://<some key> > kms.pub
-$ cosign verify --key kms.pub $IMAGE_DIGEST
+cosign public-key --key <some provider>://<some key> > kms.pub
+cosign verify --key kms.pub $IMAGE_DIGEST
 ```
 
 ## Providers
@@ -210,13 +210,13 @@ For a local setup, you can run Vault yourself or use the `docker-compose` file f
 After running it:
 
 ```shell
-$ export VAULT_ADDR=http://localhost:8200
-$ export VAULT_TOKEN=testtoken
-$ vault secrets enable transit
+export VAULT_ADDR=http://localhost:8200
+export VAULT_TOKEN=testtoken
+vault secrets enable transit
 ```
 
 If you enabled `transit` secret engine at different path with the use of `-path` flag (i.e., `$ vault secrets enable -path="someotherpath" transit`), you can use `TRANSIT_SECRET_ENGINE_PATH` environment variable to specify this path while generating a key pair like the following:
 
 ```shell
-$ TRANSIT_SECRET_ENGINE_PATH="someotherpath" cosign generate-key-pair --kms hashivault://testkey
+TRANSIT_SECRET_ENGINE_PATH="someotherpath" cosign generate-key-pair --kms hashivault://testkey
 ```

content/en/key_management/signing_with_self-managed_keys.md

@@ -4,7 +4,7 @@ category: "Key management"
 position: 505
 ---
 
-To generate a key pair in Cosign, run `cosign generate-key-pair`. You'll be interactively prompted to provide a password. 
+To generate a key pair in Cosign, run `cosign generate-key-pair`. You'll be interactively prompted to provide a password.
 
 ```shell
 $ cosign generate-key-pair
@@ -23,7 +23,7 @@ Alternatively, you can use the `COSIGN_PASSWORD` environment variable to provide
 To generate keys using a KMS provider, you can use the `cosign generate-key-pair` command with the `--kms` flag.
 
 ```shell
-$ cosign generate-key-pair --kms <some provider>://<some key>
+cosign generate-key-pair --kms <some provider>://<some key>
 ```
 
 Read more about this in the [key management overview](/key_management/overview/).