 Okay, so thanks for coming and to learn more about security hardening and the features we have been adding in Kiston in the last couple of cycles. My name is Samuelo de Medeiros Kiroyes. I am a Carby viewer in Kiston, and I'm working for SUSE. And the agenda for this talk is we are going to take a look of what PCI-DSS is. How many of you have heard of PCI-DSS or have a good notion of what it is? Cool. And then we'll be walking through the use case that drove the implementation in Kiston. Just before we dive into the implementation details and show all the options available to operators to benefit from PCI-DSS requirements. And after that, we'll be having a live demonstration of just a few of those requirements we have implemented in Kiston. And then I'm going to talk about next steps. So what's PCI-DSS? PCI-DSS stands for Payment Card Industry Data Security Standard. And they basically established the standard for applications which intend to handle credit card information. And major credit card providers require applications to meet PCI-DSS compliance in order to process data of the customers. We'll be looking at the version 3.1 of PCI-DSS in this talk. And that specific version is expressed by 12 requirements. Just to have an idea of what the requirements talk about, they cover a range of requirements from the application to the environment the application is running on. For example, the first requirement says that you should install and maintain a federal configuration to protect the cardholder data. And the five says that you should use, and regularly, up-to-date interview software in the machine you are running on application on. And the tenth says that you should track and monitor all the network resources. And the very specific requirement we'll be looking at in this talk is the eighth requirement that says you should assign a unique ID to each person with computer access. And then looking closer into that requirement, we have some requirements expressed there. For example, the 8.1.3 says that if a user gets terminated, the access to the system should be immediately revoked. The 8.1.6 says that users should have the repeated access attempts limited. And if they pass that limit with failed access attempts, their account should be locked out by 30 minutes. The 8.2.4 says that a user should change their passwords at least 90 days. And these are just a few examples. And Keystone currently, or just before we started implementing PCI DSS compliance, it already supported some of these requirements. For example, the first requirement that I mentioned that says that the user should get the access revoked could be accomplished by deleting the user in the Keystone API or by just disabling that user. However, there are some other requirements that were not met by the Keystone APIs yet. And as an example, we have the requirement that says that users should change their passwords at least every 90 days. And we have introduced a new configuration option, the Keystone configuration file, in order to make that possible. And in that case, it's called Password Expires Days. And it should be set to 90 to be in accordance with the PCI DSS specification. OK, so now that we have an idea of what's the angle, we'll be looking at PCI DSS in this talk. I would like just to highlight that we have added these security features in Neuron and Okada releases. And all the options are under the security compliance session in the Keystone configuration file. They are all disabled by default, and they are intended for the SQL backend. OK, so what's the use case for bringing some PCI DSS compliancy into Keystone? As an application writer, I want my PCI DSS compliant application to run in a PCI DSS compliant cloud environment, because I would not like to hire my application just because the cloud environment I am running my application on got exposed. So that's a pretty simple use case, and that's what drove the implementation for us in Keystone. And now I would like to walk you through all the options we support so far in our code. So the first one is the PCI DSS 8.2.6 that says that users should change their passwords upon first use after they get created and after they get an administrative reset. And that can be made available by setting the change password after first use in the Keystone configuration file. And let's just imagine a few cases here. The first code here says that the user is being created, and after that user creation, when that user tries to log in, they will get a token that's not valid anymore, and they will be required to run the second command here, which is basically resetting their own password to a new password, a brand new password. And if they forget the password or they need an administrative reset for some reason, the administrator is going to run the third command here, which is updating the user entity in the Keystone API. And after that operation, the user will be required to reset the passwords again. The second set of requirements we are looking at here is to be able to set the account lockout threshold. So PCI DSS says that after six failed attempts to log in, the user account should be locked out by 30 minutes. And this can basically be accomplished by setting the lockout failure attempts to six and lockout duration, which is expressed in seconds to 1,800, 1,800. Indicating password strength requirements. So PCI DSS requires that users' passwords should have at least seven characters and should be a mix of letters and digits. The next requirement is to require from users a unique password history. And PCI DSS expressed that a user should not be able to use one of his last four passwords. And there is a corner case here that is a user could try to run this code, which is basically trying to change the password five times in a row. And then if they get to do that, they would be able to reuse the original password that they were just using. And in order to avoid that, we have also introduced the minimal password age option in the Keystone configuration file so that you can ensure that the user is using the brand new password for at least one day in this case. The next requirement is password expiration. And PCI DSS requires that a user should be able to use the password for the maximum of 90 days. And after that, they should not be able to log in anymore and use the system before they put a new password in the system. And that's expressed by the password expires days in the configuration, which can be set to 90 to meet the PCS specification. It also says that inactive users should be disabled if they have not logged into their accounts within the last 90 days. This can be accomplished by setting the disabled user account days inactive to 90 in the configuration. And what happens specifically in Keystone is that after this given amount of days, the user gets disabled. So the enabled field of the user gets set to false. PCI DSS also talks about two-factor authentication. And Keystone currently supports it for TOTP, time-based one-time password, plus the regular password authentication. And in order to do that, a user should provide a authentication body like this one. So if I can highlight here, the fourth line says the methods. So the user specifies both methods, TOTP and password, and should contain the necessary information to authenticate against those methods inside the authentication body as well. So we can see under identity, TOTP information and the password information as well. And in order to get a valid token, both authentication methods should be successful. We might want to ignore PCI DSS requirements for a given set of users. And this can become clear if you think about the administrator of the system. We would not like to get the admin account to get locked out for a couple of days. So we can specify that by updating the user entity in the Keystone API and setting the options under the user to ignore given options. So you basically have these three options that can be ignored. So ignore lockout failure attempts, ignore password expiry, and ignore change password upon first use. So that way you protect the admin user. So now we will be having the live demonstration. And just to have an idea of how I have set up my system to this demonstration, I'm using the master version of Keystone and OpenStack Client inside the V2I environment. I am running Keystone WSJ admin using the port 35357. And I have run the commands from Keystone Manage, DBCync, and Bootstrap, passing the admin user, the admin password, and all the information needed to bootstrap the system. And I have exported the OS variables into my environment so that I'll be able to use the OpenStack CLI without needing to provide all the information, like the username and password every time. And then I was able to do an OpenStack token issue just to validate my system. An OpenStack token issue here, just to make sure it's running and working. So I was able to get a token. And I have basically exported these environment variables listed here. So I basically set the Ident API version, the project name, the domain, the user, and the password that is admin124now. So in order to show the account lockout threshold, I'm going to fail to authenticate twice. So first, before that, look at the options. I have defined the lockout failure attempts to true. And if the user fails to authenticate twice, the account is going to be locked out by 10 seconds. So I'm going to fail to authenticate twice with the admin user and try to authenticate with the right password after that, but the account's locked out and it's not going to be successful. And then we are going to wait 10 seconds and off successfully. So as I have the password already set in my environment, I'm going to override it here and try to do an OpenStack token issue. Remember the password is admin124, and I'm just using admin here. It's going to fail once, twice, and now it's locked out. And even if I try with the correct password, it's not working. It's in the account's lockout for this given user. And now, that 10 seconds has passed, we should be able to issue the token. There we go. For the next requirement, we have set the password strength requirements and I have set my configuration file to be exactly as PCI DSS requires. Just remember the password should be at least seven digits, seven characters with a mix of digits and letters. And then I'm going to try to update the admin password to something that does not match that requirement. OpenStack user password set is going to use the self-service API, not the administrative reset. And I need to provide the original password, which is the current password, original password, sorry. And then that is admin124 and then the new password. I'm going to fail with passing a password that's more than seven characters, but it does not include any digits. So the message that I have set in my configuration file is being returned to the user. So they are able to identify why the password is not being accepted. And if I try a password that has a mix of letters and digits, but it has not seven characters, it's not going to be accepted as well. And then I'm going to set a password that could be accepted, admin23. And now we should be able to do a token issue by overriding the password that I have in my environment. Cool. And the last option we'll be demonstrating here is the unique password history. And I set in my configuration file that the unique less password count should be two. So the user should not be able to reuse the current password and the last password. And I set minimum password age to zero so that we can change passwords in a row and don't need to wait days. And the plan is that I'm going to try to update it to the current password, then to the last password that was admin12. And then I update it to a third password. And that should free my very first password that was admin12. And let's see how it works. So OpenStack use a password set, the same command. So original password now is admin23. And I'm going to try to set it to the same password. And it's not going to work. Sorry, let me see. So old password and new password must be different. And if I try the original password that was admin12, that was my last password, it's not going to be allowed as well. So it says that the new password cannot be identical to a previous password. And the number of previous passwords that must be unique is two. So the current one and the last one. And now I'm going to update to a brand new password, so admin34, so that you get in the seconds. And it's going to be successful. And I should be able to do an OpenStack token issue after that. OpenStack token issue. Cool, all right. And now my very first password that was admin12 is now free. And I can reuse it. Because if you remember, the original password was admin12. And then we changed it to admin23. And now 234. And now we'll be able to reuse the admin12. I just need to fix the password here as well. And this original password is what I have in my environment. So I don't need to override it and just run OpenStack token issue. And then for next steps, we plan to improve the integration with Horizon so that it can properly show the messages. For example, for the password strength requirements to users via the dashboard, because it's not possible today, we have not implemented that yet. And we need better docs for the TrueFactor authentication. And we are willing to participate in the current discussions around PCI-DSS. I saw there was a session yesterday. And they are taking a look at PCI-DSS as a whole, like for all the services and looking at all the requirements for OpenStack. And we would like to be involved in that conversation and gladly implementing Kiston more requirements if we need to. And if you are interested on the implementation side and would like to get involved, we need help for coding. Be welcome. And just references. I got material from the PCI-DSS specification from our development specification and from the operator documentation in OpenStack as well. Cool. Now we've got time for questions. Please use the mics so that your question can be recorded. I had a question on how some of the new security compliance features may interact with different identity backends. For example, like the lockout policy. Like if you're using a different identity back end and they fail X number of times, will they be locked out at a keystone level? Or do those settings not apply in that case? Like using LDAP? Correct. So these features are intended for the SQL back end. And an operator using LDAP should be able to implement these specifications on that side. Correct. Because you may be using LDAP for more than just OpenStack, right? Correct. Yeah, I was curious if Keystone is also going to check if they have failed when it authenticates against LDAP. No. It will not check that. OK, thank you. Thank you. Any more questions? So I guess that's it. Thank you.