Control for BSI APP.4.4

[ermeratos]

Description:

Control/foundation for BSI APP.4.4 rules added

Rationale:

As we have multiple customers asking for a bsi profile to be included in the compliance-operator, we are contributing a profile. We start with a skeleton profile and will subsequently add more rules to this profile until we addressed all/most concerns

[openshift-ci]

Hi @ermeratos. Thanks for your PR.

I'm waiting for a ComplianceAsCode member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ermeratos]

/label bsi

[github-actions]

Start a new ephemeral environment with changes proposed in this pull request:

Fedora Environment

Oracle Linux 8 Environment

[openshift-ci]

@ermeratos: The label(s) /label bsi cannot be applied. These labels are supported: acknowledge-critical-fixes-only, platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, px-approved, docs-approved, qe-approved, downstream-change-needed, rebase/manual, approved, backport-risk-assessed, bugzilla/valid-bug, cherry-pick-approved, jira/valid-bug, staff-eng-approved. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

Details

In response to this:

/label bsi

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ermeratos]

/label BSI

[openshift-ci]

@ermeratos: The label(s) /label BSI cannot be applied. These labels are supported: acknowledge-critical-fixes-only, platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, px-approved, docs-approved, qe-approved, downstream-change-needed, rebase/manual, approved, backport-risk-assessed, bugzilla/valid-bug, cherry-pick-approved, jira/valid-bug, staff-eng-approved. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

Details

In response to this:

/label BSI

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jan-cerny]

/packit retest-failed

[sluetze]

sorry for the ongoing changes on this pr. The learning curve is quite steep. but this should have been it for this PR. We had a few issues with not working rules which was caused of not knowing, that we cant reference rules outside of the product we are working in.

[yuumasato]

Looks very good to me.
I have a few remarks but they are not blocking.

I'm okay if you would like to keep moving forward and address them later.

[yuumasato]

The profile names for OCP and RHCOS are versioned.
So the version should be added to the file name once it is decided what to use.

[benruland]

You mean moving the current bsi-node.profile to e.g. bsi-node-2023.profile?

Should we also add an additional bsi-node.profile file that "extends" the bsi-node-2023 profile (just like cis / cis-node do for example)?

How do you usually handle changes, when e.g. the 2024 version comes out? Remove the 2023 version and only have one version in place?

[yuumasato]

You mean moving the current bsi-node.profile to e.g. bsi-node-2023.profile?

Yes.

Should we also add an additional bsi-node.profile file that "extends" the bsi-node-2023 profile (just like cis / cis-node do for example)?

Yes.

The non-versioned profiles are always pointing to the latest version.
This way folks who want to stay on a specific version can use bsi-2022 and bsi-node-2022, for example. And folks who want to keep "rolling" to the latest version can use bsi and bsi-node.

How do you usually handle changes, when e.g. the 2024 version comes out? Remove the 2023 version and only have one version in place?

The support for versioned profiles is quite new, so we haven't gone through a profile version update yet.

But I think that update approach will depend on the lifecycle of the policy and the transition period between versions.
Is an old version immediately deprecated a new release is out? Is there a transition period?

Regardless, I can imagine that the profile for and old version will exist and be shipped for a few releases until it is removed. So that people using them can move and adapt to the new version.

[benruland]

We still got a failing test on this PR (testing-farm:centos-stream-8-x86_64). Is this related to our code changes or a false positive @yuumasato?

[yuumasato]

We still got a failing test on this PR (testing-farm:centos-stream-8-x86_64). Is this related to our code changes or a false positive @yuumasato?

I don't think the failure is related to this PR.
It looks like a infra or pipeline issue, but rebasing to latest master could help.

[BhargaviGudi]

/hold for test

[BhargaviGudi]

Verification passed with 4.14.7 + compliance-operator from code + content from PR #11342

Scenario 1: ocp4-bsi and ocp4-bsi-node

1. Install CO
2. $ oc get clusterversions.config.openshift.io 
NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.14.7    True        False         4h43m   Cluster version is 4.14.7
3. Create ssb
$ oc compliance bind -N test profile/upstream-ocp4-bsi profile/upstream-ocp4-bsi-node
Creating ScanSettingBinding test
4. Check complianceremidiation and complianceremidiationresults
$ oc get cr
No resources found in openshift-compliance namespace.
$ oc get ccr
NAME                                                   STATUS   SEVERITY
upstream-ocp4-bsi-api-server-anonymous-auth            PASS     medium
upstream-ocp4-bsi-kubeadmin-removed                    FAIL     medium
upstream-ocp4-bsi-node-master-kubelet-anonymous-auth   PASS     medium
upstream-ocp4-bsi-node-worker-kubelet-anonymous-auth   PASS     medium
upstream-ocp4-bsi-rbac-least-privilege                 MANUAL   high
$ oc get ccr upstream-ocp4-bsi-kubeadmin-removed -o=jsonpath={.instructions}
To verify that the kubeadmin secret has been deleted, make sure
that oc get secrets kubeadmin -n kube-system
returns a NotFound error.
$ oc get secrets kubeadmin -n kube-system
NAME        TYPE     DATA   AGE
kubeadmin   Opaque   1      5h2m
$ oc get ccr upstream-ocp4-bsi-rbac-least-privilege -o=jsonpath={.instructions}
The administrator must verify that Openshift is configured with the necessary RBAC access controls.

Review the RBAC configuration.

As the cluster-admin, view the cluster roles and their associated rule sets by executing the following::

oc describe clusterrole.rbac

Now view the current set of cluster role bindings, which shows the users and groups that are bound to various roles by executing the following:

oc describe clusterrolebinding.rbac

Local roles and bindings can be determined using the follow commands by executing the following:

oc describe rolebinding.rbac

If these results show users with privileged access that do not require that access, this is a finding.

Scenario 2: upstream-rhcos4-bsi

1. Create ssb
$ oc compliance bind -N test profile/upstream-rhcos4-bsi
Creating ScanSettingBinding test
2. $ oc get suite
NAME   PHASE   RESULT
test   DONE    COMPLIANT
$ oc get scan
NAME                         PHASE   RESULT
upstream-rhcos4-bsi-master   DONE    COMPLIANT
upstream-rhcos4-bsi-worker   DONE    COMPLIANT
$ oc get cr
No resources found in openshift-compliance namespace.
$ oc get ccr
NAME                                                               STATUS   SEVERITY
upstream-rhcos4-bsi-master-coreos-enable-selinux-kernel-argument   PASS     medium
upstream-rhcos4-bsi-master-selinux-policytype                      PASS     medium
upstream-rhcos4-bsi-master-selinux-state                           PASS     high
upstream-rhcos4-bsi-worker-coreos-enable-selinux-kernel-argument   PASS     medium
upstream-rhcos4-bsi-worker-selinux-policytype                      PASS     medium
upstream-rhcos4-bsi-worker-selinux-state                           PASS     high

[BhargaviGudi]

/unhold
label /qe-approved

[yuumasato]

/ok-to-test

[qlty-cloud-legacy]

Code Climate has analyzed commit 4321fcb and detected 0 issues on this pull request.

The test coverage on the diff in this pull request is 100.0% (50% is the threshold).

This pull request will bring the total coverage in the repository to 58.5% (0.0% change).

View more on Code Climate.

[yuumasato]

I'm merging the PR since the tests passed.
@ermeratos @sluetze The profile naming can be adjusted in subsequent PR's.