Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[manual-cherry-pick] Fix dead URLs #95

Merged
merged 1 commit into from
Oct 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
```
Expand All @@ -61,7 +61,7 @@ Learn how to create a custom policy, validate that the custom policy is added, a
```
[policy-name](./control-family/path/to/yaml) | <description> | <prerequisites>
```

### Validate

To validate the creation of your policy, use the Red Hat Advanced Cluster Management web console to create a new policy using our custom YAML file.
Expand All @@ -74,13 +74,13 @@ To validate the creation of your policy, use the Red Hat Advanced Cluster Manage

**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:

Expand Down
16 changes: 8 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -91,17 +91,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`.

Expand All @@ -111,7 +111,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
Expand Down Expand Up @@ -159,13 +159,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
Expand All @@ -185,7 +185,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
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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}}"
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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}}"
Expand All @@ -101,8 +101,4 @@ spec:
- requiredClusterSelector:
labelSelector:
matchLabels:
env: dev




env: dev