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

Create an ACM policy set for Advanced Cluster Security Secured Clusters #438

Merged
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
1 change: 1 addition & 0 deletions policygenerator/policy-sets/community/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ on using the policy generator.

Policy | Description | Prerequisites
------- | ----------- | -------------
[Advanced Cluster Security Secured Clusters](./acs-secure) | Applies the Advanced Cluster Security Secured Cluster operator to all managed clusters | The default placement applies the Secured Cluster resources to all OpenShift clusters except the hub cluster.
[OpenShift Best Practices](./ocp-best-practices) | Applies the OpenShift management best practices to OpenShift clusters. | Requires placement on OpenShift 4.6 clusters or newer. The `PolicySet` uses cluster `Placement` and not the `PlacementRule` placement mechanism.
[OpenShift Platform Plus (moved to stable)](../stable/openshift-plus) | The OpenShift Platform Plus policy set applies several policies that installs the OpenShift Platform Plus products using best practices that allow them to work well together. | The OpenShift Platform Plus policy set works with OpenShift managed clusters and installs many components to the hub cluster. See the policy set [README.md](../stable/openshift-plus/README.md) for more information on prerequisites. The `PolicySet` uses cluster `Placement` and not the `PlacementRule` placement mechanism.
[Kyverno Policy Sets](./kyverno) | The Kyverno policy sets are provided to help you apply best practices around security, multitenancy and applications. See the details for each each of the policy sets in the `kyverno` subdirectories. | The Kyverno `PolicySets` require the Kyverno helm chart to be installed on each managed cluster where you want to install the `PolicySets`. Use the policy [`policy-install-kyverno`](https://raw.githubusercontent.com/open-cluster-management-io/policy-collection/main/community/CM-Configuration-Management/policy-install-kyverno.yaml) to install kyverno and the policy [`policy-kyverno-config-exclude-resources`](https://raw.githubusercontent.com/open-cluster-management-io/policy-collection/main/community/CM-Configuration-Management/policy-kyverno-config-exclude-resources.yaml) to update Kyverno resource filters. The `PolicySet` uses cluster `Placement` and not the `PlacementRule` placement mechanism. For more details on Kyverno `PolicySet` installation, see the [README.md](./kyverno/README.md).
Expand Down
49 changes: 49 additions & 0 deletions policygenerator/policy-sets/community/acs-secure/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Advanced Cluster Security PolicySet for Secured Clusters

## Prerequisites

To install Advanced Cluster Security Secured Clusters using this PolicySet,
mprahl marked this conversation as resolved.
Show resolved Hide resolved
you must have already installed your Advanced Cluster Security Central Server.
The policies make the following assumptions:

- RHACS is installed on the RHACM hub and the ACS init bundle secrets are created
in the `stackrox` namespace.
- RHACS is installed on the RHACM hub and the ACS Central Server `Route` resource
exists in the `stackrox` namespace.
- An install of Red Hat Advanced Cluster Management for Kubernetes version 2.8
or newer is required.


## Installation

The ACS PolicySet for Secured Clusters contains two `PolicySets` that will be deployed.
The `PolicySets` install RHACS Secured Clusters onto all OpenShift clusters that are
managed by RHACM except for the RHACM hub cluster. If you want to install the RHACS
Secured Cluster component to the RHACM hub, that must be done separately.

Prior to applying the `PolicySet`, perform these steps:

1. Install the Policy generator Kustomize plugin by following the [installation instructions](https://github.com/open-cluster-management-io/policy-generator-plugin#installation). It is recommended to use Kustomize v4.5+.
2. Policies are installed to the `policies` namespace.
Make sure the placement bindings match this namespace for the hub and other managed clusters.
Example yaml to apply a ManagedClusterSetBinding for the policies namespace.

```yaml
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
name: default
namespace: policies
spec:
clusterSet: default
```
```bash
oc apply -f managed-cluster.yaml
```

Apply the policies using the kustomize command or subscribing to a fork of the repository and pointing to this directory. See the details for using the Policy Generator for [more information](https://github.com/stolostron/policy-collection/tree/main/policygenerator). The command to run is `kustomize build --enable-alpha-plugins | oc apply -f -`

**Note**: If the RHACS `Route` or certificate bundles are not available on the RHACM
hub cluster, you must edit the policy resources to make sure these resources are
available in the `policies` namespace.

Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
apiVersion: policy.open-cluster-management.io/v1
kind: CertificatePolicy
metadata:
name: acs-bundle-certificates
spec:
namespaceSelector:
include: ["policies"]
remediationAction: inform
severity: high
minimumDuration: 720h
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
apiVersion: v1
data: '{{ copySecretData "stackrox" "admission-control-tls" }}'
kind: Secret
metadata:
labels:
certificate_key_name: admission-control-cert.pem
name: admission-control-tls
namespace: policies
type: Opaque
---
apiVersion: v1
data: '{{ copySecretData "stackrox" "collector-tls" }}'
kind: Secret
metadata:
labels:
certificate_key_name: collector-cert.pem
name: collector-tls
namespace: policies
type: Opaque
---
apiVersion: v1
data: '{{ copySecretData "stackrox" "sensor-tls" }}'
kind: Secret
metadata:
labels:
certificate_key_name: sensor-cert.pem
name: sensor-tls
namespace: policies
type: Opaque
---
apiVersion: v1
data:
acs-host: '{{ (lookup "route.openshift.io/v1" "Route" "stackrox" "central").spec.host }}:443'
kind: ConfigMap
metadata:
name: acs-config
namespace: policies
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
apiVersion: v1
kind: Namespace
metadata:
name: stackrox
---
apiVersion: v1
kind: Namespace
metadata:
name: rhacs-operator
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: rhacs-operator-group
namespace: rhacs-operator
spec: {}
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once ACM 2.11 is out, I recommend changing this to OperatorPolicy so that the status information is much richer.

metadata:
name: rhacs-operator
namespace: rhacs-operator
spec:
channel: stable
installPlanApproval: Automatic
name: rhacs-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
---
apiVersion: v1
data: '{{hub copySecretData "policies" "admission-control-tls" hub}}'
kind: Secret
metadata:
name: admission-control-tls
namespace: stackrox
type: Opaque
---
apiVersion: v1
data: '{{hub copySecretData "policies" "collector-tls" hub}}'
kind: Secret
metadata:
name: collector-tls
namespace: stackrox
type: Opaque
---
apiVersion: v1
data: '{{hub copySecretData "policies" "sensor-tls" hub}}'
kind: Secret
metadata:
name: sensor-tls
namespace: stackrox
type: Opaque
---
apiVersion: platform.stackrox.io/v1alpha1
kind: SecuredCluster
metadata:
namespace: stackrox
name: stackrox-secured-cluster-services
spec:
clusterName: '{{hub .ManagedClusterName hub}}'
auditLogs:
collection: Auto
centralEndpoint: '{{hub fromConfigMap "" "acs-config" "acs-host" hub}}'
admissionControl:
listenOnCreates: false
listenOnEvents: true
listenOnUpdates: false
perNode:
collector:
collection: EBPF
imageFlavor: Regular
taintToleration: TolerateTaints
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
apiVersion: apps/v1
kind: Deployment
metadata:
name: sensor
namespace: stackrox
status:
conditions:
- status: "True"
type: Available
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: collector
namespace: stackrox
status:
numberMisscheduled: 0
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
generators:
- ./policyGenerator.yaml
commonLabels:
open-cluster-management.io/policy-set: acs-sensors
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
name: policy-acs-sensors
placementBindingDefaults:
name: binding-secured-clusters
policyDefaults:
categories:
- SI System and Information Integrity
controls:
- SI-5 Security Alerts Advisories and Directives
namespace: policies
policySets:
- acs-sensors-hub-info
remediationAction: enforce
severity: medium
standards:
- NIST SP 800-53
policies:
- name: policy-acs-sync-resources
consolidateManifests: false
manifests:
- path: input-sensor/policy-acs-sync-resources.yaml
- name: policy-acs-monitor-certs
dependencies:
- name: policy-acs-sync-resources
manifests:
- path: input-sensor/acs-check-certificates.yaml
- name: policy-advanced-managed-cluster-security
consolidateManifests: false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting this to false means the policy will have a lot of ConfigurationPolicies. I think these could all be in the same ConfigurationPolicy. Perhaps you could have one ConfigurationPolicy for managing the operator installation (to be replaced in 2.11) and the other could be managing the content in the stackrox namespace. Then you could use a policy dependency if you wanted to so that the first policy must be compliant before the second one activates.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I played around with this some yesterday and liked it set to false best. I can play around with some more re-organization too since I would like it to be a bit more streamlined.

manifests:
- path: input-sensor/policy-advanced-managed-cluster-security.yaml
- path: input-sensor/policy-advanced-managed-cluster-status.yaml
remediationAction: informOnly
policySets:
- acs-sensor-clusters
policySets:
- description: The Advanced Cluster Security components to setup the hub for securing
each managed cluster.
name: acs-sensors-hub-info
placement:
labelSelector:
matchExpressions:
- {key: name, operator: In, values: ["local-cluster"]}
- description: The Advanced Cluster Security components distributed to all OpenShift
managed clusters to secure the clusters.
name: acs-sensor-clusters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth having this additional policy set if it's just going to contain one policy?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like having the PolicySet even if there is only one policy.

placement:
labelSelector:
matchExpressions:
- {key: vendor, operator: In, values: ["OpenShift"]}
- {key: name, operator: NotIn, values: ["local-cluster"]}