From af1f36bde4a62fe790f967697f545937e589fe26 Mon Sep 17 00:00:00 2001 From: Enis OEZGEN Date: Wed, 2 Oct 2024 11:17:01 +0200 Subject: [PATCH] fix-dead-urls-docs Signed-off-by: Enis OEZGEN --- CONTRIBUTING.md | 16 +++++++-------- README.md | 16 +++++++-------- ...gedclustersetbinding-shared-sre-group.yaml | 20 ++++++++----------- 3 files changed, 24 insertions(+), 28 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 975f61d2d..ff8b98d36 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -38,7 +38,7 @@ The Open Cluster Management project has adopted the CNCF Code of Conduct. Refer ## Guidelines -You can use a policy from the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable), or create your own policy using the product policy framework. For more information, see _Policy overview_ in the [Open Cluster Management documentation](https://open-cluster-management.io/concepts/policy/). Use [NIST Special Publication 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) to determine the correct NIST 800-53 Control Family for the policy. +You can use a policy from the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable), or create your own policy using the product policy framework. For more information, see _Policy overview_ in the [Open Cluster Management documentation](https://open-cluster-management.io/docs/concepts/policy/). Use [NIST Special Publication 800-53](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final) to determine the correct NIST 800-53 Control Family for the policy. Start with creating your own fork and clone the `policy-collection` repository for your local environment by running the following command: `git clone https://github.com//policy-collection.git` @@ -49,7 +49,7 @@ For more information, see [GitHub documentation](https://docs.github.com/en/free Learn how to create a custom policy, validate that the custom policy is added, and add your policy to the `policy-collection` repository. Complete the following steps to create a custom policy: 1. Create a new branch to develop a custom policy: - + ``` git checkout -b no-wildcard-roles ``` @@ -57,14 +57,14 @@ Learn how to create a custom policy, validate that the custom policy is added, a 2. Create a new YAML file in the community folder that corresponds to the Security Control Family. Use the [`policy-collection/stable` folder](https://github.com/open-cluster-management-io/policy-collection/tree/main/stable) for an example of the policy framework. 3. Update the table in the [community README](https://github.com/open-cluster-management-io/policy-collection/blob/main/community/README.md) with the custom policy details by adding a new row to the table corresponding to the Security Control Family that we identified in the previous step. Provide the appropriate information in the format that is presented. For more about formatting the content, see GitHub’s Markdown guide. Your entry might resemble the following syntax: - + ``` [policy-name](./control-family/path/to/yaml) | | ``` - + ### Validate -To validate the creation of your policy, login to the Open Cluster Management hub cluster to create a new policy using our custom YAML file. +To validate the creation of your policy, login to the Open Cluster Management hub cluster to create a new policy using our custom YAML file. 1. Log in to the Open Cluster Management cluster so you can issue `kubectl` commands. @@ -72,13 +72,13 @@ To validate the creation of your policy, login to the Open Cluster Management hu **Note**: You can also validate your policy using GitOps instead of manually creating the policy. -It is important to remember to set your policy to only inform users of policy violations by default and not enforce. You can test the enforcement of the policy if your policy supports it. For more information on which policies support enforcement, see [Policy controllers](https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html/security/governance-and-risk#policy-controllers). +It is important to remember to set your policy to only inform users of policy violations by default and not enforce. You can test the enforcement of the policy if your policy supports it. For more information on which policies support enforcement, see [Policy controllers](https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html/security/governance-and-risk#policy-controllers). Be sure that your contributed policy is set to `enforce` if the intent of your policy requires something to be created. For example, a policy that creates an operator would be expected to enforce creation of the operator. On the other hand, it is recommended for a configuration policy to be set to `inform` by default so that the policy does not change cluster resources automatically when it is applied. ### Contribute -Create a pull request that can be reviewed by the product team. See the following instructions to populate a pull request: +Create a pull request that can be reviewed by the product team. See the following instructions to populate a pull request: 1. Return to the `policy-collection` directory and add all changed files with the following command: @@ -101,7 +101,7 @@ Create a pull request that can be reviewed by the product team. See the followin ``` 4. Copy and paste the URL to the pull request into your browser, which is provided in the output of the push command. Push changes from your fork back to the `open-cluster-management-io/policy-collection` repository. - + Alternatively, view the [policy-collection compare page](https://github.com/open-cluster-management-io/policy-collection/compare), select **compare across forks**, and select your fork and branch from the drop-down list. **Tip:** Provide comments in the pull request to help describe any details about your policy that may be useful to reviewers. diff --git a/README.md b/README.md index e9f9134c7..5ed5bd5b4 100644 --- a/README.md +++ b/README.md @@ -105,17 +105,17 @@ For additional information about the Policy Generator: Distributing a `Policy` to a managed cluster requires four parts, all of which must be in the same namespace: -- [Policy](https://open-cluster-management.io/concepts/policy/) is a grouping mechanism for Policy +- [Policy](https://open-cluster-management.io/docs/concepts/policy/) is a grouping mechanism for Policy Templates and is the smallest deployable unit on the hub cluster. Embedded Policy Templates are distributed to applicable managed clusters and acted upon by the appropriate `policy controller`. -- [PlacementBinding](https://open-cluster-management.io/concepts/policy/#placementbinding) binds a +- [PlacementBinding](https://open-cluster-management.io/docs/concepts/policy/#placementbinding) binds a Placement to a `Policy` or `PolicySet`. -- [Placement](https://open-cluster-management.io/concepts/placement/): Dynamically selects a set of +- [Placement](https://open-cluster-management.io/docs/concepts/placement/): Dynamically selects a set of `ManagedClusters` in one or multiple `ManagedClusterSet`s. -- [ManagedClusterSetBinding](https://open-cluster-management.io/concepts/managedclusterset/): Binds +- [ManagedClusterSetBinding](https://open-cluster-management.io/docs/concepts/managedclusterset/): Binds a `ManagedClusterSet` to a namespace, making this group of managed clusters available for selection by `Placement`. @@ -125,7 +125,7 @@ to the managed clusters and the `Policy` status will report on each cluster retu ### Using `Placement` with `Policies` -See the [Placement documentation](https://open-cluster-management.io/concepts/placement/) for +See the [Placement documentation](https://open-cluster-management.io/docs/concepts/placement/) for additional details on selecting managed clusters using `Placement`. - **NOTE:** `PlacementRule` is **deprecated**. See the @@ -173,13 +173,13 @@ those managed clusters, bringing an additional layer of control to system admini following steps on migrating from `PlacementRule` to `Placement`: 1. The desired managed clusters must be contained in a `ManagedClusterSet`. See the - [ManagedClusterSet documentation](https://open-cluster-management.io/concepts/managedclusterset/) + [ManagedClusterSet documentation](https://open-cluster-management.io/docs/concepts/managedclusterset/) to read more, including the default sets that are available that include all managed clusters that would replicate `PlacementRule` behavior. 2. Create a `ManagedClusterSetBinding` to bind the `ManagedClusterSet` to the namespace where you are authoring policies. See the - [ManagedClusterSet documentation](https://open-cluster-management.io/concepts/managedclusterset/). + [ManagedClusterSet documentation](https://open-cluster-management.io/docs/concepts/managedclusterset/). 3. Create the `Placement` manifest to replace the `PlacementRule`. To do this, take the selector `spec.clusterSelector` from the `PlacementRule` and put it into @@ -199,7 +199,7 @@ following steps on migrating from `PlacementRule` to `Placement`: - {key: environment, operator: In, values: ["dev"]} ``` -See the [Placement documentation](https://open-cluster-management.io/concepts/placement/) for +See the [Placement documentation](https://open-cluster-management.io/docs/concepts/placement/) for additional details on selecting managed clusters using `Placement`. 4. Identify any `PlacementBinding` resources that reference a `PlacementRule`. Update the diff --git a/policygenerator/policy-sets/community/kyverno/multitenancy/input/sharedresources/add-managedclustersetbinding-shared-sre-group.yaml b/policygenerator/policy-sets/community/kyverno/multitenancy/input/sharedresources/add-managedclustersetbinding-shared-sre-group.yaml index 3cda35551..eabbebed6 100644 --- a/policygenerator/policy-sets/community/kyverno/multitenancy/input/sharedresources/add-managedclustersetbinding-shared-sre-group.yaml +++ b/policygenerator/policy-sets/community/kyverno/multitenancy/input/sharedresources/add-managedclustersetbinding-shared-sre-group.yaml @@ -9,7 +9,7 @@ metadata: policies.kyverno.io/subject: ClusterRoleBinding policies.kyverno.io/description: >- Note that binding a cluster set to a namespace means that granting access from that namespace to its member clusters. And the bind process requires “managedclustersets/bind” access in the hub cluster which is clarified below. This means you can deploy an ApplicationSet to that namespace and it will be deployed on all Clusters which match the label in the Placement - read more at https://open-cluster-management.io/concepts/managedclusterset/#bind-the-clusterset-to-a-workspace-namespace + read more at https://open-cluster-management.io/docs/concepts/managedclusterset/#bind-the-clusterset-to-a-workspace-namespace spec: background: false rules: @@ -23,7 +23,7 @@ spec: - kind: Group name: "blue-sre-group" - kind: Group - name: "red-sre-group" + name: "red-sre-group" preconditions: any: - key: "{{request.operation}}" @@ -33,7 +33,7 @@ spec: - UPDATE - key: "{{request.object.metadata.name}}" operator: AnyNotIn - value: shared* + value: shared* generate: apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding @@ -53,17 +53,17 @@ spec: - kind: Group name: "red-sre-group" - kind: Group - name: "blue-sre-group" + name: "blue-sre-group" preconditions: any: - key: "{{request.operation}}" operator: In value: - CREATE - - UPDATE + - UPDATE - key: "{{request.object.metadata.name}}" operator: AnyNotIn - value: shared* + value: shared* generate: apiVersion: cluster.open-cluster-management.io/v1beta2 kind: ManagedClusterSetBinding @@ -83,7 +83,7 @@ spec: - kind: Group name: "red-sre-group" - kind: Group - name: "blue-sre-group" + name: "blue-sre-group" preconditions: any: - key: "{{request.operation}}" @@ -101,8 +101,4 @@ spec: - requiredClusterSelector: labelSelector: matchLabels: - env: dev - - - - + env: dev