diff --git a/.github/workflows/website.yaml b/.github/workflows/website.yaml index 63882b5dae4..5f9712e4bcf 100644 --- a/.github/workflows/website.yaml +++ b/.github/workflows/website.yaml @@ -1,4 +1,4 @@ -name: generate_website +name: website on: push: @@ -14,12 +14,13 @@ on: - ".github/workflows/website.yaml" - "website/**" -permissions: - contents: write +permissions: read-all jobs: deploy: runs-on: ubuntu-22.04 + permissions: + contents: write defaults: run: working-directory: website @@ -29,7 +30,7 @@ jobs: with: egress-policy: audit - - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 + - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v3.5.2 - name: Setup Node uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0 @@ -59,3 +60,17 @@ jobs: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./website/build destination_dir: ./website + + check_typos: + runs-on: ubuntu-22.04 + steps: + - name: Harden Runner + uses: step-security/harden-runner@91182cccc01eb5e619899d80e4e971d6181294a7 # v2.10.1 + with: + egress-policy: audit + + - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v3.5.2 + + - uses: crate-ci/typos@b74202f74b4346efdbce7801d187ec57b266bac8 # v1.27.3 + with: + files: ./website/docs ./website/versioned_docs diff --git a/Dockerfile b/Dockerfile index 6b3b94b9fee..b66468ac1e8 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,4 +1,4 @@ -FROM --platform=$BUILDPLATFORM golang:1.23-bookworm@sha256:0e3377d7a71c1fcb31cdc3215292712e83baec44e4792aeaa75e503cfcae16ec AS builder +FROM --platform=$BUILDPLATFORM golang:1.23-bookworm@sha256:3f3b9daa3de608f3e869cd2ff8baf21555cf0fca9fd34251b8f340f9b7c30ec5 AS builder ARG TARGETPLATFORM ARG TARGETOS diff --git a/_typos.toml b/_typos.toml new file mode 100644 index 00000000000..614e2170ece --- /dev/null +++ b/_typos.toml @@ -0,0 +1,4 @@ +[default] +extend-ignore-identifiers-re = [ + "ANDed", +] \ No newline at end of file diff --git a/gator.Dockerfile b/gator.Dockerfile index 77d959274ae..f004cfd4092 100644 --- a/gator.Dockerfile +++ b/gator.Dockerfile @@ -1,4 +1,4 @@ -FROM --platform=$BUILDPLATFORM golang:1.23-bookworm@sha256:0e3377d7a71c1fcb31cdc3215292712e83baec44e4792aeaa75e503cfcae16ec AS builder +FROM --platform=$BUILDPLATFORM golang:1.23-bookworm@sha256:3f3b9daa3de608f3e869cd2ff8baf21555cf0fca9fd34251b8f340f9b7c30ec5 AS builder ARG TARGETPLATFORM ARG TARGETOS diff --git a/website/docs/audit.md b/website/docs/audit.md index f4ff7ec2f7b..f73b9ae0649 100644 --- a/website/docs/audit.md +++ b/website/docs/audit.md @@ -116,7 +116,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -140,7 +140,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/docs/failing-closed.md b/website/docs/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/docs/failing-closed.md +++ b/website/docs/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/docs/gator.md b/website/docs/gator.md index 924aed02749..5946492dbf7 100644 --- a/website/docs/gator.md +++ b/website/docs/gator.md @@ -548,9 +548,9 @@ Certain templates require [replicating data](sync.md) into OPA to enable correct ``` This annotation contains two requirements. Requirement 1 contains two clauses. Syncing resources of group1, version3, kind1 (drawn from clause 1) would be sufficient to fulfill Requirement 1. So, too, would syncing resources of group3, version3, kind4 (drawn from clause 2). Syncing resources of group1, version1, and kind3 would not be, however. -Requirement 2 is simpler: it denotes that group5, version5, kind5 must be synced for the policy to work properly. +Requirement 2 is simpler: it denotes that group5, version5, kind5 must be synced for the policy to work properly. -This template annotation is descriptive, not prescriptive. The prescription of which resources to sync is done in `SyncSet` resources and/or the Gatekeeper `Config` resource. The management of these various requirements can get challenging as the number of templates requiring replicated data increases. +This template annotation is descriptive, not prescriptive. The prescription of which resources to sync is done in `SyncSet` resources and/or the Gatekeeper `Config` resource. The management of these various requirements can get challenging as the number of templates requiring replicated data increases. `gator sync test` aims to mitigate this challenge by enabling the user to check that their sync configuration is correct. The user passes in a set of Constraint Templates, GVK Manifest listing GVKs supported by the cluster, SyncSets, and/or a Gatekeeper Config, and the command will determine which requirements enumerated by the Constraint Templates are unfulfilled by the cluster and SyncSet(s)/Config. @@ -558,7 +558,7 @@ This template annotation is descriptive, not prescriptive. The prescription of w #### Specifying Inputs -`gator sync test` expects a `--filename` or `--image` flag, or input fron stdin. The flags can be used individually, in combination, and/or repeated. +`gator sync test` expects a `--filename` or `--image` flag, or input from stdin. The flags can be used individually, in combination, and/or repeated. ``` gator sync test --filename="template.yaml" –-filename="syncsets/" --filename="manifest.yaml" @@ -590,7 +590,7 @@ spec: kinds: ["Kind4", "Kind5"] ``` -Optionally, the `--omit-gvk-manifest` flag can be used to skip the requirement of providing a manifest of supported GVKs for the cluster. If this is provided, all GVKs will be assumed to be supported by the cluster. If this assumption is not true, then the given config and templates may cause caching errors or incorrect evaluation on the cluster despite passing this command. +Optionally, the `--omit-gvk-manifest` flag can be used to skip the requirement of providing a manifest of supported GVKs for the cluster. If this is provided, all GVKs will be assumed to be supported by the cluster. If this assumption is not true, then the given config and templates may cause caching errors or incorrect evaluation on the cluster despite passing this command. #### Exit Codes diff --git a/website/docs/metrics.md b/website/docs/metrics.md index fc3f6bf44ec..6b373327703 100644 --- a/website/docs/metrics.md +++ b/website/docs/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.10.x/audit.md b/website/versioned_docs/version-v3.10.x/audit.md index 2f812e03f5d..8f7c6d0e1b9 100644 --- a/website/versioned_docs/version-v3.10.x/audit.md +++ b/website/versioned_docs/version-v3.10.x/audit.md @@ -104,7 +104,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.10.x/failing-closed.md b/website/versioned_docs/version-v3.10.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.10.x/failing-closed.md +++ b/website/versioned_docs/version-v3.10.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.10.x/howto.md b/website/versioned_docs/version-v3.10.x/howto.md index 01b6de95c95..55b06400cdb 100644 --- a/website/versioned_docs/version-v3.10.x/howto.md +++ b/website/versioned_docs/version-v3.10.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.11.x/audit.md b/website/versioned_docs/version-v3.11.x/audit.md index 466e8efd38d..f671421d25f 100644 --- a/website/versioned_docs/version-v3.11.x/audit.md +++ b/website/versioned_docs/version-v3.11.x/audit.md @@ -111,7 +111,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.11.x/failing-closed.md b/website/versioned_docs/version-v3.11.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.11.x/failing-closed.md +++ b/website/versioned_docs/version-v3.11.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.11.x/howto.md b/website/versioned_docs/version-v3.11.x/howto.md index 01b6de95c95..55b06400cdb 100644 --- a/website/versioned_docs/version-v3.11.x/howto.md +++ b/website/versioned_docs/version-v3.11.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.12.x/audit.md b/website/versioned_docs/version-v3.12.x/audit.md index 466e8efd38d..f671421d25f 100644 --- a/website/versioned_docs/version-v3.12.x/audit.md +++ b/website/versioned_docs/version-v3.12.x/audit.md @@ -111,7 +111,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.12.x/failing-closed.md b/website/versioned_docs/version-v3.12.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.12.x/failing-closed.md +++ b/website/versioned_docs/version-v3.12.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.12.x/howto.md b/website/versioned_docs/version-v3.12.x/howto.md index 01b6de95c95..55b06400cdb 100644 --- a/website/versioned_docs/version-v3.12.x/howto.md +++ b/website/versioned_docs/version-v3.12.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.13.x/audit.md b/website/versioned_docs/version-v3.13.x/audit.md index 6188c3eba2c..f45e8da28f4 100644 --- a/website/versioned_docs/version-v3.13.x/audit.md +++ b/website/versioned_docs/version-v3.13.x/audit.md @@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/versioned_docs/version-v3.13.x/failing-closed.md b/website/versioned_docs/version-v3.13.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.13.x/failing-closed.md +++ b/website/versioned_docs/version-v3.13.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.13.x/howto.md b/website/versioned_docs/version-v3.13.x/howto.md index 764a5e85854..d235c139c5a 100644 --- a/website/versioned_docs/version-v3.13.x/howto.md +++ b/website/versioned_docs/version-v3.13.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.13.x/metrics.md b/website/versioned_docs/version-v3.13.x/metrics.md index d3b1c16f93b..c3d76b92e71 100644 --- a/website/versioned_docs/version-v3.13.x/metrics.md +++ b/website/versioned_docs/version-v3.13.x/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.14.x/audit.md b/website/versioned_docs/version-v3.14.x/audit.md index 6188c3eba2c..f45e8da28f4 100644 --- a/website/versioned_docs/version-v3.14.x/audit.md +++ b/website/versioned_docs/version-v3.14.x/audit.md @@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/versioned_docs/version-v3.14.x/failing-closed.md b/website/versioned_docs/version-v3.14.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.14.x/failing-closed.md +++ b/website/versioned_docs/version-v3.14.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.14.x/metrics.md b/website/versioned_docs/version-v3.14.x/metrics.md index d3b1c16f93b..c3d76b92e71 100644 --- a/website/versioned_docs/version-v3.14.x/metrics.md +++ b/website/versioned_docs/version-v3.14.x/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.15.x/audit.md b/website/versioned_docs/version-v3.15.x/audit.md index 6188c3eba2c..f45e8da28f4 100644 --- a/website/versioned_docs/version-v3.15.x/audit.md +++ b/website/versioned_docs/version-v3.15.x/audit.md @@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/versioned_docs/version-v3.15.x/failing-closed.md b/website/versioned_docs/version-v3.15.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.15.x/failing-closed.md +++ b/website/versioned_docs/version-v3.15.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.15.x/metrics.md b/website/versioned_docs/version-v3.15.x/metrics.md index fc3f6bf44ec..6b373327703 100644 --- a/website/versioned_docs/version-v3.15.x/metrics.md +++ b/website/versioned_docs/version-v3.15.x/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.16.x/audit.md b/website/versioned_docs/version-v3.16.x/audit.md index 6188c3eba2c..f45e8da28f4 100644 --- a/website/versioned_docs/version-v3.16.x/audit.md +++ b/website/versioned_docs/version-v3.16.x/audit.md @@ -115,7 +115,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -139,7 +139,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/versioned_docs/version-v3.16.x/failing-closed.md b/website/versioned_docs/version-v3.16.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.16.x/failing-closed.md +++ b/website/versioned_docs/version-v3.16.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.16.x/metrics.md b/website/versioned_docs/version-v3.16.x/metrics.md index fc3f6bf44ec..6b373327703 100644 --- a/website/versioned_docs/version-v3.16.x/metrics.md +++ b/website/versioned_docs/version-v3.16.x/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.16.x/validating-admission-policy.md b/website/versioned_docs/version-v3.16.x/validating-admission-policy.md index f6a7f9bcc4a..140b38b814f 100644 --- a/website/versioned_docs/version-v3.16.x/validating-admission-policy.md +++ b/website/versioned_docs/version-v3.16.x/validating-admission-policy.md @@ -131,7 +131,7 @@ labels: "gatekeeper.sh/use-vap": "yes" ``` -By default, constraints will inherit the same behavior as the constraint template. However this behavior can be overriden by adding the following label to the constraint resource: +By default, constraints will inherit the same behavior as the constraint template. However this behavior can be overridden by adding the following label to the constraint resource: ```yaml labels: diff --git a/website/versioned_docs/version-v3.17.x/audit.md b/website/versioned_docs/version-v3.17.x/audit.md index f4ff7ec2f7b..f73b9ae0649 100644 --- a/website/versioned_docs/version-v3.17.x/audit.md +++ b/website/versioned_docs/version-v3.17.x/audit.md @@ -116,7 +116,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations Limitations of getting violations from audit logs: @@ -140,7 +140,7 @@ This feature uses publish and subscribe (pubsub) model that allows Gatekeeper to Limitations/drawbacks of getting violations using pubsub channel: - There is an inherent risk of messages getting dropped. You might not receive all the published violations. -- Additional dependancy on pubsub broker. +- Additional dependency on pubsub broker. ## Running Audit For more details on how to deploy audit and diff --git a/website/versioned_docs/version-v3.17.x/failing-closed.md b/website/versioned_docs/version-v3.17.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.17.x/failing-closed.md +++ b/website/versioned_docs/version-v3.17.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.17.x/metrics.md b/website/versioned_docs/version-v3.17.x/metrics.md index fc3f6bf44ec..6b373327703 100644 --- a/website/versioned_docs/version-v3.17.x/metrics.md +++ b/website/versioned_docs/version-v3.17.x/metrics.md @@ -73,7 +73,7 @@ To see how long it takes to review a constraint kind at admission time, enable t } ``` -In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environemnt setup, like whether tracing was enabled (`TraceEnabled`). +In the excerpt above, notice `templateRunTimeNS` and `constraintCount`. The former indicates the time it takes to evaluate the number of constraints of kind `K8sRequiredLabels`, while the latter surfaces how many such constraints were evaluated for this template. Labels provide additional information about the execution environment setup, like whether tracing was enabled (`TraceEnabled`). #### Caveats diff --git a/website/versioned_docs/version-v3.6.x/audit.md b/website/versioned_docs/version-v3.6.x/audit.md index 83f527659e0..45bc8587f3b 100644 --- a/website/versioned_docs/version-v3.6.x/audit.md +++ b/website/versioned_docs/version-v3.6.x/audit.md @@ -95,7 +95,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.6.x/failing-closed.md b/website/versioned_docs/version-v3.6.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.6.x/failing-closed.md +++ b/website/versioned_docs/version-v3.6.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.6.x/howto.md b/website/versioned_docs/version-v3.6.x/howto.md index 67e491498e7..7dd956aa583 100644 --- a/website/versioned_docs/version-v3.6.x/howto.md +++ b/website/versioned_docs/version-v3.6.x/howto.md @@ -151,4 +151,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.7.x/audit.md b/website/versioned_docs/version-v3.7.x/audit.md index ded8568e2d6..d3779a51b49 100644 --- a/website/versioned_docs/version-v3.7.x/audit.md +++ b/website/versioned_docs/version-v3.7.x/audit.md @@ -95,7 +95,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.7.x/failing-closed.md b/website/versioned_docs/version-v3.7.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.7.x/failing-closed.md +++ b/website/versioned_docs/version-v3.7.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.7.x/howto.md b/website/versioned_docs/version-v3.7.x/howto.md index 67e491498e7..7dd956aa583 100644 --- a/website/versioned_docs/version-v3.7.x/howto.md +++ b/website/versioned_docs/version-v3.7.x/howto.md @@ -151,4 +151,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.8.x/audit.md b/website/versioned_docs/version-v3.8.x/audit.md index 3e4bceee2ee..74cf6376f45 100644 --- a/website/versioned_docs/version-v3.8.x/audit.md +++ b/website/versioned_docs/version-v3.8.x/audit.md @@ -95,7 +95,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.8.x/failing-closed.md b/website/versioned_docs/version-v3.8.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.8.x/failing-closed.md +++ b/website/versioned_docs/version-v3.8.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.8.x/howto.md b/website/versioned_docs/version-v3.8.x/howto.md index 01b6de95c95..55b06400cdb 100644 --- a/website/versioned_docs/version-v3.8.x/howto.md +++ b/website/versioned_docs/version-v3.8.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. diff --git a/website/versioned_docs/version-v3.9.x/audit.md b/website/versioned_docs/version-v3.9.x/audit.md index f7aa0b7ffa5..ca506b046e2 100644 --- a/website/versioned_docs/version-v3.9.x/audit.md +++ b/website/versioned_docs/version-v3.9.x/audit.md @@ -103,7 +103,7 @@ In addition to information on the violated constraint, violating resource, and v audit log entries also contain: * An `audit_id` field that uniquely identifies a given audit run. This allows indexing of historical audits -* An `event_type` field with a value of `violation_audited` to make it easy to programatically identify audit violations +* An `event_type` field with a value of `violation_audited` to make it easy to programmatically identify audit violations #### Other Event Types diff --git a/website/versioned_docs/version-v3.9.x/failing-closed.md b/website/versioned_docs/version-v3.9.x/failing-closed.md index ba1409a1f90..4d6173821e4 100644 --- a/website/versioned_docs/version-v3.9.x/failing-closed.md +++ b/website/versioned_docs/version-v3.9.x/failing-closed.md @@ -149,4 +149,4 @@ Different clusters may have different backing physical infrastructures and diffe ## Why Is This Hard? -In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubenetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. +In a nutshell it's because it's a webhook, and because it's self-hosted. All REST servers require enough high-availabily infrastructure to satisfy their SLOs (see cloud availability zones / regions). Self-hosted webhooks create a circular dependency that has the potential to interfere with the self-healing Kubernetes usually provides. Any self-hosted admission webhook would be subject to these same concerns. diff --git a/website/versioned_docs/version-v3.9.x/howto.md b/website/versioned_docs/version-v3.9.x/howto.md index 01b6de95c95..55b06400cdb 100644 --- a/website/versioned_docs/version-v3.9.x/howto.md +++ b/website/versioned_docs/version-v3.9.x/howto.md @@ -150,4 +150,4 @@ The `input.review` object stores the [admission request](https://pkg.go.dev/k8s. - `uid`: The request's unique identifier. This cannot be populated by Kubernetes for audit. - `userInfo`: The request's user's information such as `username`, `uid`, `groups`, `extra`. This cannot be populated by Kubernetes for audit. -> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources. +> **_NOTE_** For `input.review` fields above that cannot be populated by Kubernetes for audit reviews, the constraint templates that rely on them are not auditable. It is up to the rego author to handle the case where these fields are unset and empty in order to avoid every matching resource being reported as violating resources.