-
Notifications
You must be signed in to change notification settings - Fork 685
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
Add support for PCI DSS v3.2.1 for SLE12 #9613
Add support for PCI DSS v3.2.1 for SLE12 #9613
Conversation
Hi @teacup-on-rockingchair. 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 Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
40c4de8
to
e36d648
Compare
5f7c810
to
d67a660
Compare
I have realized that maybe we could have a single |
I thought about it also but what stopped me of reusing the existing control was not rules that were mostly OCP4 specific, but the notes in the pcidss_ocp4 control file which had a lot of references to Open Shift specific behaviour and OCP environment. If you think that it would be ok to put prodtype specific jinja clauses around those notes, then I guess we can easily aggregate both controls. |
It's probably ok to have a separate file then. There is also the fact that it can create a misinterpretation of the |
d67a660
to
5736db1
Compare
4a11779
to
2452191
Compare
SMEs: | ||
- abergmann | ||
|
||
reference: https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3.2.1 instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be ok in 0e0c5db
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, I've run the profile diff tool and notice that the following rules that were previously in the pci-dss.profile are not present in the pci-dss controls file:
$ ./build-scripts/profile_tool.py sub --profile1 products/sle15/profiles/pci-dss-from-main-branch.profile --profile2 build/sle15/profiles/pci-dss.profile --product sle15 --build-config-yaml build/build_config.yml --ssg-root .
selections:
- accounts_minimum_age_login_defs
- accounts_no_uid_except_zero
- accounts_password_warn_age_login_defs
- accounts_tmout
- accounts_umask_etc_bashrc
- accounts_umask_etc_login_defs
- accounts_umask_etc_profile
- cracklib_accounts_password_pam_dcredit
- cracklib_accounts_password_pam_lcredit
- cracklib_accounts_password_pam_minlen
- cracklib_accounts_password_pam_ocredit
- cracklib_accounts_password_pam_retry
- cracklib_accounts_password_pam_ucredit
- file_permissions_sshd_private_key
- file_permissions_sshd_pub_key
- no_direct_root_logins
- package_audit_installed
- package_chrony_installed
- package_openldap-clients_removed
- package_sudo_installed
- package_telnet-server_removed
- package_vsftpd_removed
- package_ypserv_removed
- postfix_network_listening_disabled
- securetty_root_login_console_only
- sshd_disable_empty_passwords
- sshd_disable_root_login
- sshd_do_not_permit_user_env
- sshd_enable_warning_banner
- sshd_set_loglevel_verbose
- sudo_add_use_pty
- sudo_custom_logfile
- var_smartcard_drivers=cac
Maybe you would like to include these rule as well so you don't end up with a different profile, at least for the transition part.
Those rules were added in the context of PCIDSS v4 effort, thanks for the feedback. For now I think is best if I include them in the context of different profile file. Once I have built a control file for that version of the standard will include them and rework the profile file. |
We should probably shift towards having version 4 as the default one. This basically means that the pci-dss.profile should point to the latest 4 version. Version 3 should eventually go away when there is the sunset and then we are left only with the pci-dss.profile identifier for example. The same for the |
In general I agree, but would prefer to do that, in the context of another PR, once I generate the control file for v4 and then will be able to rename the profiles per product. Because the v4 for SLE platforms is WIP, and I am not really aware the state of the art for the other platforms. |
That's true, ideally it would be good if we do this transition before the next release, otherwise shuffling profile IDs can cause some implications for people that already started using that specific profile ID for example. But we should be able to manage that. |
Also, if you could please rebase on top of latest main branch to check if there is no conflict with the CCE assignment since rumch-se has been including a bunch of them, just to be sure that the test will be able to catch any duplicate. Thanks. Otherwise I think we can probably merge this one. |
a3141c0
to
0b7000e
Compare
Thanks for the reminder, I just did the rebase and run the uniqe and missing cce tests for sle platforms. |
Code Climate has analyzed commit 0b7000e 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 41.2% (0.0% change). View more on Code Climate. |
Description:
Rationale: