Transcript
Hello. We are thrilled to welcome you to a session where we delve into the fascinating world of cloud infrastructure and security. Today, our attention is directed not only towards protecting sensitive data, but also towards the efficient deployment and management of Vault across various types of infrastructure. Imagine a world where your cloud infrastructure operates flawlessly. I know, I know, but it is possible. This is not just a dream, but a reality we are creating by harnessing the power of Ansible, a robust automation tool. Our journey begins with setting up a Vault cluster using Ansible. As we dive deeper, we'll talk about the synergy between Vault's Auto-Unseal function and Azure Key Vault. This isn't just a pairing, it acts as a powerful alliance that presents a robust method for handling secrets and secure data in cloud environments. But our exploration doesn't end there. We'll also examine the setup of another Vault cluster, one that employs the Transit Secrets engine. This cluster doesn't operate in isolation. It relies on the central Vault cluster for its unsealing. Here we'll witness first-hand the flexibility and interconnected nature of Vault, and how it provides a layered security framework, adding depth and resilience to our cloud infrastructure. Finally, we'll dive into the integration of OpenID Connect with Microsoft EntraID, formerly known as Azure AD. This is a crucial component in the realm of identity and access management, offering a secure and efficient pathway for authentication and authorization in cloud applications. So buckle up as we embark on this journey together, exploring the depths of automation and security. And thank you for joining us today. So, as usual, Elif is outsourcing this slide to me, so I'll make the introduction. Here it goes. I am a senior solution architect with over 20 years of experience. My skill set includes a wide range of experience in system and network administration, automation, and security. Elif is a senior DevOps engineer, having considerable experience in implementing, administrating, and optimizing everything related to infrastructure. Her dedication and active involvement in IT communities is evident through her consistent contributions, whether through delivering informative and engaging talks, or through her well-written pieces on a multitude of topics. We are both HashiCorp ambassadors and co-organizers for local meetups. We represent Infinity Group, an IT service company offering managed services, application management, support, and IT strategy consulting from our main office in Bucharest, Romania. Let me change the slide. And I think you don't really see it all. Now it's better. So Vault, a bird's eye view. HashiCorp Vault is an indispensable tool in modern infrastructure for its robust handling of sensitive data and credentials. At its core, Vault is designed for secure secret management, ensuring that critical information like API keys, passwords, certificates are stored and accessed securely. This is especially important in cloud-based and distributed systems where data security is paramount. One of Vault's standout features is the ability to encrypt data both at rest and in transit, a crucial aspect in meeting data protection regulations and maintaining data privacy. Moreover, Vault's approach to identity-based access management allows for fine-grained control over who can access specific secrets, adhering to the principle of least privilege, a fundamental security best practice. For Vault, dynamic secrets capability is particularly significant. Unlike static credentials that pose a risk if compromised, Vault generates short-lived dynamic credentials, reducing the likelihood of unauthorized access. This feature not only enhances security but also simplifies credential rotation and management. Operating seamlessly with multiple platforms, Vault is versatile and adaptable to different environments from small-scale projects to large, complex enterprise systems. Its scalability and flexibility coupled with robust disaster recovery and replication features ensures that it remains a reliable and consistent solution when in multi-cloud or highly available scenarios. Thank you, Andrei, for such a nice introduction about Vault. Let's now take a closer look at Vault Auto Unseal. This feature is designed to simplify the process of unsealing Vault, which is an essential step to access the data which is stored within it. Normally, Vault starts in a sealed state and requires a set of unsealed keys, typically held by separate individuals, to access its contents. This process is important for security but can be cumbersome, especially in automated environments. Moreover, the unseal feature enhances the reliability and availability of services dependent on Vault. In a manual unsealing process, the availability of Vault is directly tied to the availability of the personnel holding the unsealed keys. This dependence can pose significant risks, especially in scenarios like off-hours incidents or situations where key holders are unavailable. Auto Unseal mitigates these risks by ensuring that Vault can be automatically unsealed and made available as needed without human intervention. This reliability is particularly important for organizations that require high uptime and fast recovery times in case of outages or restarts, ensuring that access to secrets and credentials is consistently maintained. Let's talk about Vault Auto Unseal strategies. You could use cloud provider services. Major cloud providers like AWS, Azure, GCP or Alicloud offer cryptographic key management systems which Vault can use to provide the root key for the unsealed operation. For instance, the KMS in AWS can be used to store and provide the root key to the startup's Vault cluster. Similarly, Azure Key Vault and GCP Cloud KMS can be configured for Auto Unsealing Vault. We could also Auto Unseal using the Transit Secret Engine. This method enables operators to delegate the unsealing process to a trusted Vault environment, easing operation by using Vault's Transit Secret Engine for Auto Unsealing. Of course, we could use a hardware security module to unseal. Vault Enterprise offers a more secure method using this hardware security module. It stores and retrieves the root key using AHSM, providing enhanced security as all parts of the secret management infrastructure. However, this method requires stringent security policies and management of access to the hardware security module. Let's now take a closer look to Azure Key Vault. This is a cloud service which is provided by Microsoft Azure and it aims to provide secure key management and cryptographic services. Vault, as I was saying in the introduction, the main cluster is configured to use Azure Key Vault as an Auto Unseal mechanism. This means that Vault will rely on Azure Key Vault for cryptographic operations needed to unseal itself. When Vault is first initialized, its master key is split into multiple key shares. Instead of distributing these key shares to individuals, the master key is encrypted with Azure Key Vault's keys and stored securely. When Vault restarts or is in a sealed state, it automatically reaches out to Azure Key Vault to decrypt its stored master key. This process does not require any human intervention, thereby speeding up the access to Vault and enabling more automated workflows. Azure Key Vault provides additional security features such as logging and strict access controls, which can be beneficial for compliance and, of course, auditing purposes. Moving on, we'll look at the Transit Secrets engine, which is to be used by the second Vault cluster. The Transit Secrets engine is a feature of Vault that provides encryption as a service. It allows us to encrypt and decrypt data via API calls without exposing the encryption keys. By integrating the Transit Secrets engine with the Auto Unseal process, Vault is able to utilize an external Vault's Transit Secrets engine to store and manage the unsealed keys. So, how does this workflow actually look like? Firstly, on startup, the sealed Vault sends a request to an external Vault instance that is configured with the Transit Secrets engine. The external Vault uses the stored unsealed keys to generate an unsealed token and sends it back to the sealed Vault. The sealed Vault then uses the token to unseal itself automatically. Well, when considering the implementation of a secrets management system, particularly for the purpose of unsealing secure environments such as HashiCorp Vault, the choice of the right unsealing mechanism is crucial. The use of HashiCorp's Transit Secrets engine presents a unique set of advantages, especially when contrasted with other solutions such as Azure Key Vault or AWS KMS. Some of these benefits would be centralization and scalability, seamless integration with the Vault ecosystem. Let's take a closer look at this. About centralization and scalability, well, one of the primary benefits of using the Transit Secrets engine is its ability to centralize key management in an environment where multiple Vault instances are in operation. This centralization actually simplifies the management of encryption keys, reducing the complexity typically associated with handling numerous keys across various systems. This centralization not only enhances security oversight, but also significantly scales the organization's growth. The Transit Secrets engine is adept at handling large volumes of keys and high throughput, a feature particularly beneficial for expanding enterprises. Well, a seamless integration in the Vault ecosystem, organizations which are already leveraging HashiCorp Vault are most likely to find the Transit Secrets engine a natural fit. Designed to integrate seamlessly with the Vault ecosystem, it minimizes compatibility issues and maximizes the utility of existing Vault features. This interoperability fosters a more cohesive security infrastructure, ensuring that all components work in harmony. Encryption as a service and enhanced security. The Transit Secrets engine offers encryption as a service, handling not only encryption and decryption tasks, but also managing cryptographic functions without exposing the keys. This encapsulation adds an extra layer of security. Furthermore, Vault's robust audit logging capabilities extend to the Transit Secrets engine, enabling tracking and auditing of keys usage and access patterns, which are crucial for maintaining a high security standard. The integration of Vault's policy-based access control with the Transit Secrets engine ensures that only authorized entities are able to access or perform operations on the key, thereby heightening security. Additionally, the ability to automate the unsealing process of Vault using the Transit Secrets engine reduces operational overhead and minimizes human error, which is often actually a significant vulnerability in security systems. Lastly, an important advantage of using the Transit Secrets engine is the reduction of independence on external cloud providers. This independence is particularly valuable for organizations adopting hybrid or multi-cloud strategies as it mitigates vendor lock-in and provides more flexibility. Unlike cloud-specific solutions, the Transit Secrets engine can be customized to suit unique organizational needs, offering a more adaptable and flexible approach to key management. That's quite a lot of information, but definitely there are advantages to using the Transit Automation. I fully agree. So let's move on to the Vault OIDC Auth method. The OIDC authentication method is a feature that allows Vault to authenticate users based on their identity as verified by an OIDC provider. So OIDC is an authentication layer built on top of Auth2.0 method, which allows clients to verify the identity of an end user and to obtain basic profile information about that particular end user. So speaking about the flow, the authentication flow, a user or application requests authentication from Vault using the OIDC method. Vault redirects the user to their OIDC provider for authentication. After the authentication, the OIDC provider returns an ID token to the user, and then the user provides this ID token to Vault. Vault will verify the ID token with the OIDC provider, and if the token is valid and the user has the appropriate role, Vault provides a token granting access to its stored secret. How about use cases? First, it comes in mind the single sign-on. It allows users to log in Vault using their existing single sign-on credentials. But we should also mention automated authentication, because it enables automated systems and services to authenticate with Vault using OIDC. Things to take into consideration. Consider complexity. Setting up OIDC can be complex and requires an understanding of both OIDC protocol and Vault authentication methods. And think about the dependence on external providers, because you rely on the availability and security of the external OIDC provider. Moving on. Okay, and now we'll be integrating Microsoft EnterID, the former Microsoft Azure AD, with Vault. Well, how does this integration actually look like? This integration leverages standard authentication protocols such as OpenID Connect or SML 2.0. Microsoft EnterID, I might at times use Azure ID because it is like, well, commonly used in the community. So bear with me. These support these protocols, which make it furthermore compatible with HashiCorp Vault. So how would the setup would look like? On the Azure side, this involves setting up an application in Azure, configuring the necessary permissions and obtaining the client ID, tenant ID and secret key. We are soon going to actually show you how this looks like. On the Vault side, this needs to be configured to recognize and authenticate users from Microsoft EnterID. This is done by setting up an authentication method in Vault that points to the Azure, to the application configured in Azure. How the user would actually use this authentication method? So users attempting to access HashiCorp Vault are redirected then to Azure AD for authentication. Upon successful login, Azure AD issues an identity token. This token is then presented to Vault, which validates it and grants access based on the configured policies. This flow is also available in the diagram you are able to see. Well, on the administration side, Vault administrators are able to map Azure AD groups or roles to specific policies in Vault, controlling what users are able to access within Vault based on their Azure AD role or group membership. I think we'll be able to see this in the following demonstration. Indeed. So let me switch to the terminal. I think it's now OK. As part of our demonstration, we are employing Ansible, and to be more precise, Ansible roles, in order to firstly set up the Vault cluster, which is going to use the Transit Secrets engine in order to automatically unseal. So let's take a closer look at this. I'm running the Vault YML playbook, which calls upon the Vault role. And you are able to see the steps Ansible takes in order to accomplish these. Firstly, the necessary packages are installed, the required directories are created. The Vault configuration file is being deployed using a Jinja template. So this is highly customizable, let's say. Then the Vault service is started and enabled, so that in case the server gets rebooted, the service would automatically start. We also added some checks in order to check that the Vault API is actually reachable. And the last task, which informs us about the status of the members. So we are able to see that the Vault is initialized, unsealed and active, and also that the other two members are stand-by. Maybe before we can go on, show us the Jinja template? Yes, of course. So this is how the template looks like. We are able to customize the cluster name to set certain, let's say, TTL or default TTL. We are able to take the API address, the cluster address. We also are able to choose what kind of backend to use. So we could, for example, choose to use the console as a backend or use Raft. There are also other backends available. I would not like for you guys to think that only these two are available. But for us, these were the use cases necessary, and this is why we have configured these. However, this is easily extendable, right, Andrei? Yeah, it is. And how about the unsealed? Yeah, let me quickly go on to the unsealed state. I hoped to look there. So, look here, sealed transit. This takes certain, let's say, environment variables, which are loaded in my current terminal, and it will configure these. So the sealed transit address, the sealed transit token, the key name, the month path, are loaded from my current environment variables and being passed on to the Vault cluster. Does this answer your question, Andrei? Yes, it does. Let's now check out the Vault cluster and what we have done. Oh, I think I should have exported my environment variables. Guys, despite the fact that I'm going to export the token, I'm going to say it is not very secure, but we are going to tear down our Vault cluster right after this demonstration. So it is highly not recommended to share tokens lively or in a recording, but this is just for demonstration purposes. We usually use some tooling like DRAM for exposing those variables without actually committing them to the terminal, but it works for this demonstration. Indeed. The point was here for you to see that this Vault cluster is using the Transit Secrets engine in order to be out on sealed, and also you are able to see that it uses the Raft backend. Let's go on. Should I show the Azure part? Yes, please. I think that would be a great opportunity to explore what has been done on the Azure side. Let me publish that information, so only our users are in this demo terminal. To make all work, we need an up-registration. It's quite simple. You just create one. The most important thing is to actually configure the URLs, callback URLs, which you can see here, and some API permissions, which you can see here. Upon configuring everything related to this up-registration, Ansible will be able to make the configuration as well, and things will get working. Should I show logging in as well? Not yet. That is the final step. Don't skip it. Let me go on, and let's try to actually enable the OADC authentication method. Is my screen on? Ready, yes. Thank you. So, employing Ansible. Oops. Oops. Something did not work correctly. Connection reset by peer, so I think this is a transient because I did encounter it quite sometimes. Yep. Happens at times because of the, let's say, community plugins are not always, well, there might be some failures at times. What I actually wanted to show you guys, and it is important, the OIDC authentication method, it is not to be configured on the whole cluster automatically. It is based, its configuration or enabling is based on a Boolean, which is by default turned off. It is enough to use only one of the, as targets, only one of the servers, because this action takes upon the whole cluster. And up to this point, I think, Andrei, you will only be able to authenticate to Vault. However, you would not be granted any privileges. Let me actually now grant you some privileges, and you should be able to see. Thank you. To access the Hacintox 2024 secret engine. This is mapped to one Azure AD group. Again, an issue here. It is the same as something related to Python. Okay. Let me run it again. Oh. Doing more verbose. It worked. Yep. Okay. Usually, using the verbose mode always helps me to better identify the issues. However, I suppose it is something related to Python. Now, can I show the login port? Yes. You have been waiting for this, right? Yeah. So, I am going to our Vault, and just select the required method. And because I'm already signed in to Azure, I will be able to access Vault. But I can only see the cubbyhole engine. Let me try again. But this time, I'll use a role as well. And because of that role, and the matching behind the scenes, I'll be able to see, hopefully, yes, the Hacintox 2024 engine with one value. Hello, world. I don't think I've been so inspired. It's good. Okay. Should we move to conclusions? I think it's high time to. Okay. Let me change the slide, please. Here you go. So, thank you all for your time and attention today. We'd be happy to answer any questions you may have, or discuss any points in more detail. Please feel free to reach out anytime. Thank you. Thank you.
