vale: enable Microsoft.FirstPerson and Microsoft.Terms

.vale.ini

@@ -13,7 +13,9 @@ Vale.Terms = NO
 Microsoft.HeadingAcronyms = NO  # doesn't consider well-known ones
 Microsoft.GeneralURL = NO  # ok for technical users
 Microsoft.SentenceLength = NO # TODO(katexochen): should we enable this?
+Microsoft.FirstPerson = error
 Microsoft.OxfordComma = error
+Microsoft.Terms = error
 
 # Only selectively enable rules from the Google ruleset.
 Google.Acronyms = NO
@@ -31,7 +33,6 @@ Google.HeadingPunctuation = NO
 Google.Headings = NO
 Google.Latin = NO
 Google.LyHyphens = NO
-Google.meta.json = NO
 Google.OptionalPlurals = NO
 Google.Ordinal = NO
 Google.OxfordComma = NO

docs/docs/architecture/attestation.md

@@ -102,7 +102,7 @@ It plays a critical role in preventing unauthorized changes and detecting potent
 The attestation provides integrity and authenticity guarantees, enabling relying parties—such as workload operators or data owners—to confirm the effective protection against potential threats, including malicious cloud insiders, co-tenants, or compromised workload operators.
 More details on the specific security benefits can be found [here](../basics/security-benefits.md).
 
-### How can I verify the authenticity of attestation results?
+### How can you verify the authenticity of attestation results?
 
 Attestation results in Contrast are tied to cryptographic proofs generated and signed by the hardware itself.
 These proofs are then verified using public keys from trusted hardware vendors, ensuring that the results aren't only accurate but also resistant to tampering.

docs/docs/getting-started/cluster-setup.md

@@ -4,7 +4,6 @@
 
 Install the latest version of the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/).
 
-
 [Login to your account](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli), which needs
 to have the permissions to create an AKS cluster, by executing:
 
@@ -44,7 +43,7 @@ az feature show \
     --output table
 ```
 
-Afterwards, refresh the registration of the ContainerService provider:
+Afterward, refresh the registration of the ContainerService provider:
 
 ```sh
 az provider register \
@@ -118,7 +117,6 @@ az aks nodepool add \
   --workload-runtime KataCcIsolation
 ```
 
-
 Optionally, we can now remove the non-CoCo node pool:
 
 ```bash

docs/docs/troubleshooting.md

@@ -20,6 +20,7 @@ problem lies.
 The logs from the Coordinator and the Initializer can be configured via the
 environment variables `CONTRAST_LOG_LEVEL`, `CONTRAST_LOG_FORMAT` and
 `CONTRAST_LOG_SUBSYSTEMS`.
+
 - `CONTRAST_LOG_LEVEL` can be set to one of either `debug`, `info`, `warn`, or
   `error`, similar to the CLI (defaults to `info`).
 - `CONTRAST_LOG_FORMAT` can be set to `text` or `json`, determining the output
@@ -81,7 +82,7 @@ LAST SEEN  TYPE     REASON  OBJECT             MESSAGE
 
 A common error, as in this example, is that the container creation was blocked by the
 policy. Potential reasons are a modification of the deployment YAML without updating
-the policies afterwards, or a version mismatch between Contrast components.
+the policies afterward, or a version mismatch between Contrast components.
 
 ### Regenerating the policies
 

docs/versioned_docs/version-0.5/getting-started/cluster-setup.md

@@ -4,7 +4,6 @@
 
 Install the latest version of the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/).
 
-
 [Login to your account](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli), which has
 the permissions to create an AKS cluster, by executing:
 
@@ -44,7 +43,7 @@ az feature show \
     --output table
 ```
 
-Afterwards, refresh the registration of the ContainerService provider:
+Afterward, refresh the registration of the ContainerService provider:
 
 ```sh
 az provider register \

docs/versioned_docs/version-0.6/architecture/attestation.md

@@ -5,21 +5,23 @@ The following gives a detailed description of Contrast's attestation architectur
 At the end of this document, we included an [FAQ](#frequently-asked-questions-about-attestation-in-contrast) that answers the most common questions regarding attestation in hindsight of the [security benefits](../basics/security-benefits.md).
 
 ## Attestation architecture
+
 Contrast integrates with the RATS architecture, leveraging their definition of roles and processes including *Attesters*, *Verifiers*, and *Relying Parties*.
 
 ![Conceptual attestation architecture](../_media/attestation-rats-architecture.svg)
 
 Figure 1: Conceptual attestation architecture. Taken from [RFC 9334](https://www.rfc-editor.org/rfc/rfc9334.html#figure-1).
 
-
 - **Attester**: Assigned to entities that are responsible for creating *Evidence* which is then sent to a *Verifier*.
 - **Verifier**: These entities utilize the *Evidence*, *Reference Values*, and *Endorsements*. They assess the trustworthiness of the *Attester* by applying an *Appraisal Policy* for *Evidence*. Following this assessment, *Verifiers* generate *Attestation Results* for use by *Relying Parties*. The *Appraisal Policy* for *Evidence* may be provided by the *Verifier Owner*, programmed into the *Verifier*, or acquired through other means.
 - **Relying Party**: Assigned to entities that utilize *Attestation Results*, applying their own appraisal policies to make specific decisions, such as authorization decisions. This process is referred to as the "appraisal of Attestation Results." The *Appraisal Policy* for *Attestation Results* might be sourced from the *Relying Party Owner*, configured by the owner, embedded in the *Relying Party*, or obtained through other protocols or mechanisms.
 
 ## Components of Contrast's attestation
+
 The key components involved in the attestation process of Contrast are detailed below:
 
 ### Attester: Application Pods
+
 This includes all Pods of the Contrast deployment that run inside Confidential Containers and generate cryptographic evidence reflecting their current configuration and state.
 Their evidence is rooted in the [hardware measurements](../basics/confidential-containers.md) from the CPU and their [confidential VM environment](../components/runtime.md).
 The details of this evidence are given below in the section on [evidence generation and appraisal](#evidence-generation-and-appraisal).
@@ -43,6 +45,7 @@ When provided with the policy from the Kata host, the guest agent verifies that
 In summary a Pod's evidence is the attestation report of the CPU that provides evidence for runtime environment and the runtime policy.
 
 ### Verifier: Coordinator and CLI
+
 The [Coordinator](../components/index.md#the-coordinator) acts as a verifier within the Contrast deployment, configured with a [Manifest](../components/index.md#the-manifest) that defines the reference values and serves as an appraisal policy for all pods in the deployment.
 It also pulls endorsements from hardware vendors to verify the hardware claims.
 The Coordinator operates within the cluster as a confidential container and provides similar evidence as any other Pod when it acts as an attester.
@@ -57,31 +60,32 @@ The [CLI](../components/index.md#the-cli-command-line-interface) serves as the v
 These reference values are built into the CLI during our release process and can be reproduced offline via reproducible builds.
 
 ### Relying Party: Data owner
+
 A relying party in the Contrast scenario could be, for example, the [data owner](../basics/security-benefits.md) that interacts with the application.
 The relying party can use the CLI to obtain the attestation results and Contrast's [CA certificates](certificates.md) bound to these results.
 The CA certificates can then be used by the relying party to authenticate the application, for example through TLS connections.
 
-
 ## Evidence generation and appraisal
 
 ### Evidence types and formats
+
 In Contrast, attestation evidence revolves around a hardware-generated attestation report, which contains several critical pieces of information:
 
 - **The hardware attestation report**: This report includes details such as the chip identifier, platform information, microcode versions, and comprehensive guest measurements. The entire report is signed by the CPU's private key, ensuring the authenticity and integrity of the data provided.
 - **The launch measurements**: Included within the hardware attestation report, this is a digest generated by the CPU that represents a hash of all initial guest memory pages. This includes essential components like the kernel, initramfs, and the kernel command line. Notably, it incorporates the root filesystem's dm-verity root hash, verifying the integrity of the root filesystem.
 - **The runtime policy hash**: Also part of the hardware attestation report, this field contains the hash of the Rego policy which dictates all expected API commands and their values from the host to the Kata guest agent. It encompasses crucial settings such as dm-verity hashes for the container image layers, environment variables, and mount points.
 
 ### Appraisal policies for evidence
+
 The appraisal of this evidence in Contrast is governed by two main components:
 
 - **The Manifest**: A JSON file used by the Coordinator to align with reference values. It sets the expectations for runtime policy hashes for each pod and includes what should be reported in the hardware attestation report for each component of the deployment.
 - **The CLI's appraisal policy**: This policy encompasses expected values of the Coordinator’s guest measurements and its runtime policy. It's embedded into the CLI during the build process and ensures that any discrepancy between the built-in values and those reported by the hardware attestation can be identified and addressed. The integrity of this policy is safeguardable through reproducible builds, allowing verification against the source code reference.
 
-
-
 ## Frequently asked questions about attestation in Contrast
 
 ### What's the purpose of remote attestation in Contrast?
+
 Remote attestation in Contrast ensures that software runs within a secure, isolated confidential computing environment.
 This process certifies that the memory is encrypted and confirms the integrity and authenticity of the software running within the deployment.
 By validating the runtime environment and the policies enforced on it, Contrast ensures that the system operates in a trustworthy state and hasn't been tampered with.
@@ -98,7 +102,7 @@ It plays a critical role in preventing unauthorized changes and detecting potent
 The attestation provides integrity and authenticity guarantees, enabling relying parties—such as workload operators or data owners—to confirm the effective protection against potential threats, including malicious cloud insiders, co-tenants, or compromised workload operators.
 More details on the specific security benefits can be found [here](../basics/security-benefits.md).
 
-### How can I verify the authenticity of attestation results?
+### How can you verify the authenticity of attestation results?
 
 Attestation results in Contrast are tied to cryptographic proofs generated and signed by the hardware itself.
 These proofs are then verified using public keys from trusted hardware vendors, ensuring that the results aren't only accurate but also resistant to tampering.

docs/versioned_docs/version-0.6/getting-started/cluster-setup.md

@@ -43,7 +43,7 @@ az feature show \
     --output table
 ```
 
-Afterwards, refresh the registration of the ContainerService provider:
+Afterward, refresh the registration of the ContainerService provider:
 
 ```sh
 az provider register \

docs/versioned_docs/version-0.7/architecture/attestation.md

@@ -5,21 +5,23 @@ The following gives a detailed description of Contrast's attestation architectur
 At the end of this document, we included an [FAQ](#frequently-asked-questions-about-attestation-in-contrast) that answers the most common questions regarding attestation in hindsight of the [security benefits](../basics/security-benefits.md).
 
 ## Attestation architecture
+
 Contrast integrates with the RATS architecture, leveraging their definition of roles and processes including *Attesters*, *Verifiers*, and *Relying Parties*.
 
 ![Conceptual attestation architecture](../_media/attestation-rats-architecture.svg)
 
 Figure 1: Conceptual attestation architecture. Taken from [RFC 9334](https://www.rfc-editor.org/rfc/rfc9334.html#figure-1).
 
-
 - **Attester**: Assigned to entities that are responsible for creating *Evidence* which is then sent to a *Verifier*.
 - **Verifier**: These entities utilize the *Evidence*, *Reference Values*, and *Endorsements*. They assess the trustworthiness of the *Attester* by applying an *Appraisal Policy* for *Evidence*. Following this assessment, *Verifiers* generate *Attestation Results* for use by *Relying Parties*. The *Appraisal Policy* for *Evidence* may be provided by the *Verifier Owner*, programmed into the *Verifier*, or acquired through other means.
 - **Relying Party**: Assigned to entities that utilize *Attestation Results*, applying their own appraisal policies to make specific decisions, such as authorization decisions. This process is referred to as the "appraisal of Attestation Results." The *Appraisal Policy* for *Attestation Results* might be sourced from the *Relying Party Owner*, configured by the owner, embedded in the *Relying Party*, or obtained through other protocols or mechanisms.
 
 ## Components of Contrast's attestation
+
 The key components involved in the attestation process of Contrast are detailed below:
 
 ### Attester: Application Pods
+
 This includes all Pods of the Contrast deployment that run inside Confidential Containers and generate cryptographic evidence reflecting their current configuration and state.
 Their evidence is rooted in the [hardware measurements](../basics/confidential-containers.md) from the CPU and their [confidential VM environment](../components/runtime.md).
 The details of this evidence are given below in the section on [evidence generation and appraisal](#evidence-generation-and-appraisal).
@@ -43,6 +45,7 @@ When provided with the policy from the Kata host, the guest agent verifies that
 In summary a Pod's evidence is the attestation report of the CPU that provides evidence for runtime environment and the runtime policy.
 
 ### Verifier: Coordinator and CLI
+
 The [Coordinator](../components/index.md#the-coordinator) acts as a verifier within the Contrast deployment, configured with a [Manifest](../components/index.md#the-manifest) that defines the reference values and serves as an appraisal policy for all pods in the deployment.
 It also pulls endorsements from hardware vendors to verify the hardware claims.
 The Coordinator operates within the cluster as a confidential container and provides similar evidence as any other Pod when it acts as an attester.
@@ -57,31 +60,32 @@ The [CLI](../components/index.md#the-cli-command-line-interface) serves as the v
 These reference values are built into the CLI during our release process and can be reproduced offline via reproducible builds.
 
 ### Relying Party: Data owner
+
 A relying party in the Contrast scenario could be, for example, the [data owner](../basics/security-benefits.md) that interacts with the application.
 The relying party can use the CLI to obtain the attestation results and Contrast's [CA certificates](certificates.md) bound to these results.
 The CA certificates can then be used by the relying party to authenticate the application, for example through TLS connections.
 
-
 ## Evidence generation and appraisal
 
 ### Evidence types and formats
+
 In Contrast, attestation evidence revolves around a hardware-generated attestation report, which contains several critical pieces of information:
 
 - **The hardware attestation report**: This report includes details such as the chip identifier, platform information, microcode versions, and comprehensive guest measurements. The entire report is signed by the CPU's private key, ensuring the authenticity and integrity of the data provided.
 - **The launch measurements**: Included within the hardware attestation report, this is a digest generated by the CPU that represents a hash of all initial guest memory pages. This includes essential components like the kernel, initramfs, and the kernel command line. Notably, it incorporates the root filesystem's dm-verity root hash, verifying the integrity of the root filesystem.
 - **The runtime policy hash**: Also part of the hardware attestation report, this field contains the hash of the Rego policy which dictates all expected API commands and their values from the host to the Kata guest agent. It encompasses crucial settings such as dm-verity hashes for the container image layers, environment variables, and mount points.
 
 ### Appraisal policies for evidence
+
 The appraisal of this evidence in Contrast is governed by two main components:
 
 - **The Manifest**: A JSON file used by the Coordinator to align with reference values. It sets the expectations for runtime policy hashes for each pod and includes what should be reported in the hardware attestation report for each component of the deployment.
 - **The CLI's appraisal policy**: This policy encompasses expected values of the Coordinator’s guest measurements and its runtime policy. It's embedded into the CLI during the build process and ensures that any discrepancy between the built-in values and those reported by the hardware attestation can be identified and addressed. The integrity of this policy is safeguardable through reproducible builds, allowing verification against the source code reference.
 
-
-
 ## Frequently asked questions about attestation in Contrast
 
 ### What's the purpose of remote attestation in Contrast?
+
 Remote attestation in Contrast ensures that software runs within a secure, isolated confidential computing environment.
 This process certifies that the memory is encrypted and confirms the integrity and authenticity of the software running within the deployment.
 By validating the runtime environment and the policies enforced on it, Contrast ensures that the system operates in a trustworthy state and hasn't been tampered with.
@@ -98,7 +102,7 @@ It plays a critical role in preventing unauthorized changes and detecting potent
 The attestation provides integrity and authenticity guarantees, enabling relying parties—such as workload operators or data owners—to confirm the effective protection against potential threats, including malicious cloud insiders, co-tenants, or compromised workload operators.
 More details on the specific security benefits can be found [here](../basics/security-benefits.md).
 
-### How can I verify the authenticity of attestation results?
+### How can you verify the authenticity of attestation results?
 
 Attestation results in Contrast are tied to cryptographic proofs generated and signed by the hardware itself.
 These proofs are then verified using public keys from trusted hardware vendors, ensuring that the results aren't only accurate but also resistant to tampering.

docs/versioned_docs/version-0.7/getting-started/cluster-setup.md

@@ -4,7 +4,6 @@
 
 Install the latest version of the [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/).
 
-
 [Login to your account](https://docs.microsoft.com/en-us/cli/azure/authenticate-azure-cli), which needs
 to have the permissions to create an AKS cluster, by executing:
 
@@ -44,7 +43,7 @@ az feature show \
     --output table
 ```
 
-Afterwards, refresh the registration of the ContainerService provider:
+Afterward, refresh the registration of the ContainerService provider:
 
 ```sh
 az provider register \
@@ -118,7 +117,6 @@ az aks nodepool add \
   --workload-runtime KataCcIsolation
 ```
 
-
 Optionally, we can now remove the non-CoCo node pool:
 
 ```bash

docs/versioned_docs/version-0.8/architecture/attestation.md

@@ -102,7 +102,7 @@ It plays a critical role in preventing unauthorized changes and detecting potent
 The attestation provides integrity and authenticity guarantees, enabling relying parties—such as workload operators or data owners—to confirm the effective protection against potential threats, including malicious cloud insiders, co-tenants, or compromised workload operators.
 More details on the specific security benefits can be found [here](../basics/security-benefits.md).
 
-### How can I verify the authenticity of attestation results?
+### How can you verify the authenticity of attestation results?
 
 Attestation results in Contrast are tied to cryptographic proofs generated and signed by the hardware itself.
 These proofs are then verified using public keys from trusted hardware vendors, ensuring that the results aren't only accurate but also resistant to tampering.