CMP-2460: PCI-DSS 4 requirement 8 #12148
Conversation
The applicable requirements can be automated on OpenShift. However, the payment entity will still need to apply the same requirement onto their payment application.
Among many requirements not applicable one is supported.
|
Start a new ephemeral environment with changes proposed in this pull request: Fedora Environment Oracle Linux 8 Environment |
|
🤖 A k8s content image for this PR is available at: Click here to see how to deploy itIf you alread have Compliance Operator deployed: Otherwise deploy the content and operator together by checking out ComplianceAsCode/compliance-operator and: |
Sections 8.2 and 8.3 are heavily dependant on the selected identity provider and removal of kubeadmin user. So rules for these tow aspects were added to the controls.
|
/hold for test |
| needs to be removed. | ||
| rules: | ||
| - idp_is_configured | ||
| - kubeadmin_removed |
There was a problem hiding this comment.
Does rule ocp4-ocp-idp-no-htpasswd need to be added here as the tile said "Strong authentication for users and administrators is established and managed"
There was a problem hiding this comment.
What about the rule "ocp_no_ldap_insecure"?
There was a problem hiding this comment.
+1
I think those two rules should be added here:
- ocp_idp_no_htpasswd
- ocp_no_ldap_insecure
There was a problem hiding this comment.
Thanks for the reviews.
I have added ocp_no_ldap_insecure under 8.3.2. the rule is about making sure LDAP doesn't transmit clear passwords.
And have added ocp_idp_no_htpasswd under 8.3.4, PCI-DSS is okay with using passwords as an authentication mechanism, and requirement 8.3.6 establishes strong parameters for this password. However, the htpaswd identity provider doesn't provide user lockout, which is required by 8.3.4.
| time that a session can be active. However, the payment entity also needs to control the | ||
| user's and administrator's idle session timeouts on their payment applications as well. | ||
| rules: | ||
| - oauth_or_oauthclient_inactivity_timeout |
There was a problem hiding this comment.
Should we add oauth_or_oauthclient_token_maxage here?
There was a problem hiding this comment.
I don't think so, the requirement is about login out the user or locking his session when inactive.
And the rule is about expiry of the OAuth token, which forces the user to re-authenticate after some time.
There is nothing regarding periodic re-authentication in the standard.
controls/pcidss_4_ocp4.yml
Outdated
| @@ -2144,10 +2199,11 @@ controls: | |||
| interception of communications or from stored data. | |||
| levels: | |||
| - base | |||
| status: pending | |||
| status: not applicable | |||
There was a problem hiding this comment.
wondering if ocp_no_ldap_insecure also applies to here, since it is related to transmission of password
The choice of which identity provider to use falls onto the payment entity. But we already know that htpaswd cannot satisfy PCI-DSS's needs, and LDAP provider needs to be restrained. Restrict usage of htpasswd as the identity provider, it cannot provide user lockout feature required by PCI-DSS. Do not allow the LDAP provider to transmit clear text passwords.
There was a problem hiding this comment.
/lgtm
But I'll give @xiaojiey and @Vincent056 a chance to review the latest updates.
|
Code Climate has analyzed commit c6eac49 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 59.4% (0.0% change). View more on Code Climate. |
|
/lgtm |
Description:
8.1is not applicableManaging users identification and the its processes is responsibility of the payment entity.
8.2is automatedIdentification in OpenShift is handled by an identity provider, and most requirements are not applicable. However, Openshift can prevent login from shared generic users like
rootandkubeadmin.8.3,8.4and8.5are not applicableThese requirements are to be implemented in the identity provider deployed by the payment entity.
8.6is supportedTo prevent hardcoding of secrets in scripts and applications, Openshift supports integration with third party secret vaults.