 Let's start. I'm really very surprised. There are lots of people here in the room. I wasn't expecting it, but again, good. Yeah, good, thank you. OK, room is even full, and no others are let in. But that's great. That tells me that what we have created is actually useful and creates some interest in the community. I'm not a member of HashiCorp. I'm not selling it. It's just basically we created something for OpenStack, and it works for Vault with Vault, and it helps us manage our credentials securely. So this actually everything based on our own history. We have our own deployments, and in all of our deployments we need to manage our own secrets. Let's have a look on which particular types of secrets are the most common. We have SSH keys, database credentials. We have usually API tokens. Maybe, of course, maybe not. TLS certificates and cloud credentials. List is not complete and doesn't even pretend to be complete. This is not really the purpose here. It's just a couple of examples. So keeping the secrets safe. How actually we solve the problem? We have our secrets, and we need to keep them safe. We usually, the first real approach would be keep them as plain text on the file system. A little bit more advanced use case. Let's try to have encrypted files on the file system. A little bit more advanced, really, depending on which type of encryption you select. Then the next advanced use case would be encrypted files, but let's keep them in git. We would like, basically, to have a proper CI CD. We would like to have proper versioning, so let's try to keep them in git. And then we have the whole variety of different vault-based solutions. Ansible Vault, Bitward, and HashiCorp Vault, which we are going to talk about now. And again, list is incomplete. There are tons of ways, so we are not pretending, and we are not saying that this is the only way how we should do. This is only a possibility. So looking to HashiCorp Vault, we have secrets engines there that are helping us to store credentials there and to get them then out of vault in, so to say, secure way. Let's hope that the user implemented all of the policies properly, and this is really secure, but that is also not our target here. So there is support for TLS certificates in Hashi Vault. There is support for SSH keepers, database credentials, key value store for pretty much everything that's not supported, so something very universal. AWS, HRGCP, but what about OpenStack have we saw? There is no support for OpenStack credentials in HashiCorp Vault, and therefore, we made this. So idea is simple. Put credentials, put OpenStack credentials into Vault. Define roles, what you as a user would expect to get from Vault, to read from Vault, you can have a token for the session, for the regular Keystone token. You can eventually would like to get a temporary user with a password, let's say, I would like to provision my infrastructure, and for this particular provisioning, I would like that only a temporary user is created, which is then afterwards immediately deleted. Of course, this is just a brief example, but you can do it this way. We deal through the roles with project and domain scopes. You remember, we have username and password, and with this, you can get project scope for one project, project scope token for another project, domain scope token, and the whole variety of other things. So with roles, we try to deal also with that. We actually also thought, well, looking a little bit further into the future, we would like to make our Ansible, probably basically relying on this functionality, and Ansible kind of connection, which is eventually also other tools, they would like to have like Cloud YAML entry. The ones here, someone of you may know already how Cloud YAML file look like, and that would basically be just one of the entries in the Cloud YAML, so through the help of roles, we can say, please return me the whole structure, and this is really a structure with what makes it a little bit more complex. And of course, as an administrator operator of Vault, you would map roles to Vault policies, those two particular users, whatever, whatever, exactly to be able to define which particular user of the Vault is having access to which particular role in Vault, which would particularly map to some specific project, but not the other project, only one project, but not another project, still the same user password. So here we have definitely possibility to map things a little bit even more, to make them even more complex. Sorry guys, this is not making life easier, but a little bit more complex even give you more possibilities. So, oh, sorry, going down. The reference flow, number one, application requests Cloud credentials from Vault. Number two, Vault goes itself to the identity and gets the token. Basically, either token or a temporary user, it depends on what we have, actually how we configured it. Vault receive token back from identity. Vault gives the token back to the application, and application goes directly to Cloud resources themselves and do whatever it needs. That is more or less the reference workflow, how we think it should be. Example, now we are really already on the example so it's not going to be really very deep. We configure credentials inside of Vault. So I'm explicitly here not demonstrating how to install the plugin into Vault. If you have Vault installation, you know how to do this, otherwise this is also pretty good described already. And somewhere else in the Vault documentation, or also, of course, in the documentation for the plugin. So for Particular Cloud, we are giving back to the Vault username, password, user domain name, username template, what would be interesting once we would like to get temporary users. And password policy, because in a Particular Cloud, you might be having different requirements to your passwords and through the Vault policies, we have possibility really to say which particular character sets are required in this particular password. So good. Next, creating a two different roles. First one, temporary user. Basically, what we say here in the Vault, we configure role TMP user, which would refer to Cloud example Cloud from the step above. And it would give us a temporary user with the project name MyProject in the particular domain, with particular user groups, and that is also something where once you create a temporary user, you might want to assign it to particular groups. So that is also what we have here. Rootfalls, this is something that we would be coming shortly and secret type token. Basically, every time for the temporary user, we have possibility to get back token or the password. For the root role, we have actually possibility only to get a token. So generally, once we provision a superpower user in Vault that is able to create other users, this is really critical stuff. And we would like to ensure that basically this password never leaves the Vault. This is pretty much exactly already if you have experience with Vault in the database, a secret engine, it is working exactly the same way. So password of the admin user that you use for the connection will never leave Vault. But instead, in the second case, root is equal to true and secret type is token. So basically for the root user, we would still be able to get a token. Let's say something in our application is not able to do things how we want and we need to do it somehow differently. And we still need to get token for this particular super user, to create users on some other side to grant some additional privileges outside of Vault. Whatever, use cases are pretty much limitless here. You can find always some corner case where you will need this possibility. So those are two different examples, but generally in reality, there are three examples. For temporary user, you can get back token or password. And for root user, you can get only token. Root explicitly here in quotes. And now let's have a look how to actually request credentials back. Again, use case for CLI, really native Vault CLI. Vault read credentials. Basically, again, here the ones who have already experienced with Hashi Vault will recognize this looks really very similar to how a database credentials are done. So read credentials from a particular role that we have configured previously, what we get back, lease, lease duration, renewable, and the whole authentication map, which is you recognize most likely already something that is looking like Cloud YAML, where we have, of course, token. Next use case, let's have a look how to use API for that. Curl, passing some Vault token, whatever it is, and pretty much the same endpoint, and that is what you get back. Pretty much exactly the same data, just using API and not CLI. Next thing, exactly basically was our use case. We would like to make use with Ansible from there. So we first read credentials with already existing Hashi Vault collection and Ansible module from the Vault, and then simply pass, and that is exactly where it comes handy that we get from Vault plugin already the full Cloud YAML structure, because this is exactly what Ansible would be expecting here. So that's it, pretty much. With Ansible, there is nothing more. That is pretty straightforward. Another example, Terraform. I'm not pretending here to be showing very sophisticated Terraform use case. It just exactly describes the same how to start using it. So we describe data, provider Vault, data source, yeah, data, which is also pointing again here. Oh, selection is working a little bit differently, but good. Then we try, and that is something we faced with Terraform. Once you get back complex JSON structure, you need to do some processing in order to be able to pass it further in Terraform. But generally, the only thing we need is have a data source pointing to Vault, process the response of it, and pass it further to the open stack provider as here. Again, yeah, good. You see, house URL, house token. Pretty much that's it. You have nothing else. Okay, that was actually it from the use cases summary. We are already close to the summary. Root password never leaves Vault. That gives us some security. We have some powerful user on some external system, and we would like to ensure that the password will not leak this. Very sensitive password will not leak. It doesn't save you. Please remember, it doesn't still save you. If the token is leaked and the token is not revoked, intruder may still use it. So it's not about the fact that you will get absolute privacy here, absolute security here. You still need to keep in mind all of the other aspects, how to deal with secrets. It's just that you have some other alternative way of protection. What we have implemented, automatic root password rotation, at the moment what we have, you have provisioned an administrator user in Vault, and the password never leaves it. How do you change password? There is no way other than the plugin is able to do this itself. So at the moment we have a special commando that will trigger a password rotation, and what is really in scope is that we actually even try to watch how identity, what identity tells if it says the password rotation is due, please do it. On the other side, of course, we also, once we are provisioning this account into the Vault, we are able to say that, we would be able to say, please rotate password every one month. Good, next, get token for root with scope. That is what we have seen. We have provisioned this admin account into the Vault, and we are able to get token for this particular root user. Normally you shouldn't need that, but under some circumstances you might want that. Get token for temporary user with scope, and that's also one of the really useful cases where, for example, for doing integration tests of your application, you would like to have simply a dynamic user there. So, that's where we have this possibility, getting basically both token or password depending on your application needs. And, of course, last but not least, temporary user will have its TTL, which is configurable, of course, and would be dropped automatically by Vault once the lease expires. Resource cleanup, question mark. That is something where we are not sure that is actually never, should never be in scope of the Vault, but actually once you create dynamic user and use this particular user, you might start thinking, okay, and what do I do with everything what the user has done in the cloud? So, that's explicitly here, not in the scope. Just remember that if you start using the plugin, you need to keep that in mind somehow. Roadmap. Handover to community. We created it for satisfying our own needs, but we are really willing to, so to say, get rid of it and give it back to community to start relying on open development, what should be our targets. Next point is really where I'm as a PTL for the OpenStack client also having interest to integrate support into the Cloud YAML. The idea of having something like that and use it with Ansible and Terraform is cool, but how can I use this with OpenStack client? Because that's also logically, I would like to get rid of my plain text passwords for any kind of user that is written in my Cloud YAML in my environment variables, whatever else I'm using. So, that is our current roadmap. There is no progress on it at all so far. That is really just an idea and target. And last but not least here, any ideas from you as people who might be thinking, who might be having additional ideas, what additional use case can we make out of it? Pretty much we are on the Q&A. Any particular questions? Would you please be so kind and go to the microphone? I was asked that because of the recording, everyone is going to the mic. This is Joo Young-Wok from Samsung SDS. I have a question about regarding boards. After configuring Secret Bag End as board, in point of use and use, how can you know the board is working well? Some kind of workflow? Can you please repeat? I barely hear you from here. Yeah. Can I open? Yeah. After configuring Secret Bag End as board, we want to check the board configuration is working well. So, if the board configuration works well, we can see any secret in the barbecue. So, your question is going towards Barbican? Yeah, I think that board is concerned with Barbican configuration. Barbican is actually here, not involved at all. This is really from the client perspective. As a client, let's say even imagine this OpenStack client support is implemented. You have a Cloud YAML, you are a regular user, and you would like that your OpenStack server list comment will simply grab password from somewhere and will return your back data. So, it has so far nothing to do with Barbican. It's really your user perspective on the whole idea. In my company, we are computing some OpenStack YAS platform. In the first time, we are going to configure Secret Bag End as simple crypto of the Barbican service. And then, in the future, we are going to reconfigure as the Secret Bag End with HushCop board. So, I think the Barbican service is related with port and simple crypto things. If I understand you correctly, you still talk about you as so to say close to operator stuff, where you deploy some services. This is really only user oriented. This has nothing to do with operation. This has no influence on Barbican. Eventually, if we find the use case, how Barbican can make use of that. That would be a totally different story. But at the moment, this is strictly addressing really a regular user, a regular cloud user, which knows nothing about the cloud. You mean this port is not related with Barbican service in OpenStack? It has nothing to do with Barbican at all. Okay. Yeah, thank you. Any other questions? Well, if no, then no. Thanks a lot. The one who may want to ask me, you still would be able to see me through the summit on different sessions. Come join our booth of OpenTelecom Cloud. Again, this is not a sailing point. This is just, we are there. And it's not that we created it for, but we need it and we are part of the community. We would like to share. Thank you very much. Thank you.