{"id":18515,"date":"2024-10-08T21:57:24","date_gmt":"2024-10-08T21:57:24","guid":{"rendered":"https:\/\/www.directimpactsolutions.com\/?page_id=18515"},"modified":"2024-10-08T21:57:26","modified_gmt":"2024-10-08T21:57:26","slug":"server-configuration-zero-trust","status":"publish","type":"page","link":"https:\/\/www.directimpactsolutions.com\/en\/server-configuration-zero-trust\/","title":{"rendered":"Server Configuration Zero Trust"},"content":{"rendered":"
<\/path><\/svg><\/div>
<\/div>\n\n

Server Configuration for a Zero Trust Solution<\/h2>\n\n

Steps for configuring servers in a Zero Trust solution<\/p>\n\n

<\/div><\/div><\/div>
<\/div>

Here are the steps for configuring the Zero Trust solution:<\/p>

Boundary Server at AWS<\/h2>

1. Deploy an Ubuntu Server 24.04 LTS instance according to HashiCorp’s recommendations<\/a>. <\/p>

In the following example, we’ll be deploying an m6i.large instance, which meets the requirements of a small-scale deployment. If you’re deploying on Azure or GCP, the recommended instance types are also mentioned in the link.<\/p>

\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>

<\/p>

2. Make sure that the security group associated with the instance has ports 80 (http), 443 (https), 8200 (Vault) and 9202 (Boundary Worker) open for all IPs, as well as 9201 and 9203 (Remote Boundary Worker) at your office IP address, and of course that you have SSH access to the instance from your workstation only.<\/p>

\"\"<\/figure>

<\/p>

3. Assign a static IP (Elastic IP address at AWS) and create a DNS entry at your registrar to use a domain name to connect to the instance.<\/p>

\"\"<\/figure>

<\/p>

4. Connect to the instance via SSH once deployed to start software installation.<\/p>

Install Boundary Controller and Worker on AWS Instance<\/h2>

5. The Boundary controller requires Postgres SQL, so start by installing it:<\/p>

sudo apt install postgresql postgresql-contrib\nsudo systemctl start postgresql.service\nsudo systemctl enable postgresql.service<\/code><\/pre>
6. You then need to create a boundary database and a user to connect to it. Since Postgres version 15, you also need to add an additional permission to be able to create tables in the newly created database.<\/p>
sudo -i -u postgres\npsql\ncreate database boundarydb;\ncreate user boundary with password 'password';\ngrant all privileges on database boundarydb to boundary;\n\\c boundarydb;\nGRANT ALL ON SCHEMA public TO boundary;\nexit\nexit<\/code><\/pre>
7. We can now move on to the Boundary installation stage. Here’s the procedure for Ubuntu, but Boundary is also available for macOS, Windows and several Linux variants.<\/p>
wget -O- https:\/\/apt.releases.hashicorp.com\/gpg | sudo gpg --dearmor -o \/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg\necho \"deb [signed-by=\/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg] https:\/\/apt.releases.hashicorp.com $(lsb_release -cs) main\" | sudo tee \/etc\/apt\/sources.list.d\/hashicorp.list\nsudo apt update && sudo apt install boundary<\/code><\/pre>
8. Then create a controller.hcl file in the Boundary folder.<\/p>
sudo vi \/etc\/boundary.d\/controller.hcl<\/code><\/pre>
9. And insert the necessary information. Here’s an example file. At the very least, you need to adjust the database url section if you’ve used a user or password other than those mentioned above, as well as the domain name or public IP address of your Boundary server in the public_cluster_addr section.<\/p>
# Disable memory lock: https:\/\/www.man7.org\/linux\/man-pages\/man2\/mlock.2.html\ndisable_mlock = true\n\n# Controller configuration block\ncontroller {\n  # This name attr must be unique across all controller instances if running in HA mode\n  name = \"controller-1\"\n  public_cluster_addr=\"boundary.yourdomain.com\"\n  description = \"First controller\"\n\n  # After receiving a shutdown signal, Boundary will wait 10s before initiating the shutdown process.\n  graceful_shutdown_wait_duration = \"10s\"\n\n  # Database URL for postgres. This can be a direct \"postgres:\/\/\"\n  # URL, or it can be \"file:\/\/\" to read the contents of a file to\n  # supply the url, or \"env:\/\/\" to name an environment variable\n  # that contains the URL.\n  database {\n      url = \"postgresql:\/\/boundary:password@127.0.0.1:5432\/boundarydb\"\n  }\n}\n\n# API listener configuration block\nlistener \"tcp\" {\n  # Should be the address of the NIC that the controller server will be reached on\n  address = \"0.0.0.0\"\n  # The purpose of this listener block\n  purpose = \"api\"\n\n  tls_disable = true\n\n  # Uncomment to enable CORS for the Admin UI. Be sure to set the allowed origin(s)\n  # to appropriate values.\n  #cors_enabled = true\n  #cors_allowed_origins = [\"https:\/\/yourcorp.yourdomain.com\", \"serve:\/\/boundary\"]\n}\n\n# Data-plane listener configuration block (used for worker coordination)\nlistener \"tcp\" {\n  # Should be the IP of the NIC that the worker will connect on\n  address = \"0.0.0.0:9201\"\n  # The purpose of this listener\n  purpose = \"cluster\"\n}\n\nlistener \"tcp\" {\n  # Should be the address of the NIC where your external systems'\n  # (eg: Load-Balancer) will connect on.\n  address = \"0.0.0.0:9203\"\n  # The purpose of this listener block\n  purpose = \"ops\"\n\n  tls_disable = true\n}\n\n# Root KMS configuration block: this is the root key for Boundary\n# Use a production KMS such as AWS KMS in production installs\nkms \"aead\" {\n  purpose = \"root\"\n  aead_type = \"aes-gcm\"\n  key = \"XXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"\n  key_id = \"global_root\"\n}\n\n# Worker authorization KMS\n# Use a production KMS such as AWS KMS for production installs\n# This key is the same key used in the worker configuration\nkms \"aead\" {\n  purpose = \"worker-auth\"\n  aead_type = \"aes-gcm\"\n  key = \"XXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"\n  key_id = \"global_worker-auth\"\n}\n\n# Recovery KMS block: configures the recovery key for Boundary\n# Use a production KMS such as AWS KMS for production installs\nkms \"aead\" {\n  purpose = \"recovery\"\n  aead_type = \"aes-gcm\"\n  key = \"XXXXXXXXXXXXXXXXXXXXXXXXXXXX\"\n  key_id = \"global_recovery\"\n}<\/code><\/pre>
10. As we will also be using this server as a Worker, we also need to create a worker file or modify the existing one.<\/p>
sudo vi \/etc\/boundary.d\/worker.hcl<\/code><\/pre>
11. Make sure that the following information is correctly configured. Be sure to enter the DNS you’ve created in the public_addr section, and to include information in the tags section that will allow you to differentiate between different workers.<\/p>
# # Note that this is an example systemd file and is not intended to be functional as-is.\n# # Full configuration options can be found at https:\/\/www.boundaryproject.io\/docs\/configuration\/worker\n\n listener \"tcp\" {\n     purpose = \"proxy\"\n     tls_disable = true\n     address = \"0.0.0.0\"\n }\n\nworker {\n#   # Name attr must be unique across workers\n   name = \"worker-aws\"\n#   description = \"A default worker created demonstration\"\n\n#   # Workers must be able to reach controllers on :9201\n   controllers = [\n     \"127.0.0.1\",\n#     \"10.0.0.2\",\n#     \"10.0.0.3\",\n   ]\n\n   public_addr = \"worker-aws.yourdomain.com\"\n\n   tags {\n     type   = [\"prod\", \"aws\"]\n     region = [\"ca-central-1\"]\n   }\n }\n\n# # must be same key as used on controller config# \n kms \"aead\" {\n     purpose = \"worker-auth\"\n     aead_type = \"aes-gcm\"\n     key = \"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"\n     key_id = \"global_worker-auth\"\n }<\/code><\/pre>
12. The first time we start the controller, we need to initialize the database. This will create an account that allows access to the web interface. Enter the following command and be sure to take note of the information displayed:<\/p>
sudo boundary database init -config \/etc\/boundary.d\/controller.hcl<\/code><\/pre>
13. Now we need to start the controller and the worker. If you don’t want to have to restart them every time the server is restarted, you can create services. Here’s how to create the controller:<\/p>
sudo vi \/etc\/systemd\/system\/boundarycontroller.service<\/code><\/pre>
14. Enter the following information in the file:<\/p>
[Unit]\nDescription=Boundary Controller\n\n[Service]\nType=simple\nUser=root\nExecStart=\/usr\/bin\/boundary server -config=\/etc\/boundary.d\/controller.hcl\nRestart=always\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>
15. We need to create a second one for the worker.<\/p>
sudo vi \/etc\/systemd\/system\/boundaryworker.service<\/code><\/pre>
16. Enter the following information in the file :<\/p>
[Unit]\nDescription=Boundary Worker\n\n[Service]\nType=simple\nUser=root\nExecStart=\/usr\/bin\/boundary server -config=\/etc\/boundary.d\/worker.hcl\nRestart=always\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>
17. All that remains is to start them up and activate them on reboot.<\/p>
sudo systemctl start boundarycontroller\nsudo systemctl status boundarycontroller\nsudo systemctl enable boundarycontroller\nsudo systemctl start boundaryworker\nsudo systemctl status boundaryworker\nsudo systemctl enable boundaryworker<\/code><\/pre>
18. Boundary uses its own port, but if we want to secure the connection with an SSL certificate, it’s possible to deploy a web server in front of it. To do this, we’ll use Apache combined with Certbot<\/a> to generate a free SSL certificate, but it would also be possible to use Nginx<\/a> with a purchased certificate as well.<\/p>
sudo apt install apache2
sudo a2enmod proxy_http
sudo apt install certbot python3-certbot-apache<\/code><\/pre>
19. Once Apache has been installed, the default configuration file must be modified or a new one created before the SSL certificate can be installed and connected to Boundary.<\/p>
sudo vi \/etc\/apache2\/sites-enabled\/000-default.conf<\/code><\/pre>
20. Be sure to modify the ServerName section to reflect your domain name and to replace\/deactivate the DocumentRoot section with the Proxy values.<\/p>
<VirtualHost *:80>\n        # The ServerName directive sets the request scheme, hostname and port that\n        # the server uses to identify itself. This is used when creating\n        # redirection URLs. In the context of virtual hosts, the ServerName\n        # specifies what hostname must appear in the request's Host: header to\n        # match this virtual host. For the default virtual host (this file) this\n        # value is not decisive as it is used as a last resort host regardless.\n        # However, you must set it for any further virtual host explicitly.\n        #ServerName www.example.com\nProxyPreserveHost On\nProxyRequests Off\nServerName boundary.yourdomain.com\nProxyPass \/ http:\/\/localhost:9200\/\nProxyPassReverse \/ http:\/\/localhost:9200\/\n#       ServerAdmin webmaster@localhost\n#       DocumentRoot \/var\/www\/html\n\n        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,\n        # error, crit, alert, emerg.\n        # It is also possible to configure the loglevel for particular\n        # modules, e.g.\n        #LogLevel info ssl:warn\n\n        ErrorLog ${APACHE_LOG_DIR}\/error.log\n        CustomLog ${APACHE_LOG_DIR}\/access.log combined\n        \n        # For most configuration files from conf-available\/, which are\n        # enabled or disabled at a global level, it is possible to\n        # include a line for only one particular virtual host. For example the\n        # following line enables the CGI configuration for this host only\n        # after it has been globally disabled with \"a2disconf\".\n        #Include conf-available\/serve-cgi-bin.conf\n<\/VirtualHost>\n\n# vim: syntax=apache ts=4 sw=4 sts=4 sr noet<\/code><\/pre>
21. Now all that’s left to do is restart apache and generate the SSL certificate:<\/p>
sudo systemctl restart apache2\nsudo certbot --apache<\/code><\/pre>
22. Once you’ve answered the various questions, you should have a generated SSL certificate.<\/p>
23. Now it’s time to validate that your Boundary installation is up and running before moving on to the next step. Use your web browser to connect to the domain name you used to generate the SSL certificate. If the SSL certificate installation has been completed successfully, you should now have access to the Boundary page, which asks you to identify yourself.<\/p>
\"\"<\/figure>
<\/p>
24. Log in using the admin account created during the database initiation stage.<\/p>
25. When the database was created, Boundary created an organization by default. You can delete it and create a new one later. For now, make sure your worker is connected by clicking on the \u201cWorkers\u201d section.<\/p>
\"\"<\/figure>
<\/p>
Installing Boundary Worker on a Hyper-V Virtual Machine<\/h2>
We’ll assume that you already have a physical server running Windows Server 2019 and the Hyper-V role. This server is configured inside your company network. It would be possible to do the same deployment with another hypervisor, regardless of whether it’s type 1 or type 2, as long as it’s on a different network from your Boundary controller.<\/p>
1. Retrieve the Ubuntu Server<\/a> 24.04 LTS installation file if you don’t already have it on your physical server.<\/p>
2. Create a new virtual machine with at least a 2-core processor, 8 GB of memory and 50 GB of disk space.<\/p>
3. Start the virtual machine and follow the steps to install Ubuntu Server. Be sure to enable OpenSSH Server installation during installation and ideally assign it a static IP address or make a reservation on your DHCP server.<\/p>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
\"\"<\/figure>
<\/p>
4. Connect to your virtual machine via SSH once it has been rebooted.<\/p>
5. Install Boundary as follows:<\/p>
wget -O- https:\/\/apt.releases.hashicorp.com\/gpg | sudo gpg --dearmor -o \/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg\necho \"deb [signed-by=\/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg] https:\/\/apt.releases.hashicorp.com $(lsb_release -cs) main\" | sudo tee \/etc\/apt\/sources.list.d\/hashicorp.list\nsudo apt update && sudo apt install boundary<\/code><\/pre>
6. Create a worker file:<\/p>
sudo vi \/etc\/boundary.d\/worker.hcl<\/code><\/pre>
7. Instead of connecting it to 127.0.0.1, you’ll need to connect it to the address of your AWS controller that you created earlier. You should also make sure to enter the DNS you created in the public_addr section, and to include information in the tags section that will allow you to differentiate between different workers.<\/p>
# # Note that this is an example systemd file and is not intended to be functional as-is.\n# # Full configuration options can be found at https:\/\/www.boundaryproject.io\/docs\/configuration\/worker\n\n listener \"tcp\" {\n     purpose = \"proxy\"\n     tls_disable = true\n     address = \"0.0.0.0\"\n }\n\nworker {\n#   # Name attr must be unique across workers\n   name = \"worker-mainoffice\"\n#   description = \"A default worker created demonstration\"\n\n#   # Workers must be able to reach controllers on :9201\n   controllers = [\n     \"X.X.X.X:9201\",\n#     \"10.0.0.2\",\n#     \"10.0.0.3\",\n   ]\n\n   public_addr = \"worker-mainoffice.yourdomain.com\"\n\n   tags {\n     type   = [\"prod\", \"mainoffice\"]\n#     region = [\"ca-central-1\"]\n   }\n }\n\n# # must be same key as used on controller config# \n kms \"aead\" {\n     purpose = \"worker-auth\"\n     aead_type = \"aes-gcm\"\n     key = \"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\"\n     key_id = \"global_worker-auth\"\n }<\/code><\/pre>
8. If we want to make sure we don’t have to restart it every time the server is restarted, we can create a service.<\/p>
sudo vi \/etc\/systemd\/system\/boundaryworker.service<\/code><\/pre>
9. Enter the following information in the file:<\/p>
[Unit]\nDescription=Boundary Worker\n\n[Service]\nType=simple\nUser=root\nExecStart=\/usr\/bin\/boundary server -config=\/etc\/boundary.d\/worker.hcl\nRestart=always\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>
10. Then all that’s left to do is start it up and activate it:<\/p>
sudo systemctl start boundaryworker\nsudo systemctl status boundaryworker\nsudo systemctl enable boundaryworker<\/code><\/pre>
11. Now you just have to make sure that the 9202 is redirected to your Worker Boundary in your router.<\/p>
12. Once this is done, you’ll be able to use it via the main Boundary server. If you return to the Boundary server web interface, you should now see 2 workers listed:<\/p>
\"\"<\/figure>
<\/p>
13. You can deploy as many workers as you need, depending on the number of internal networks you need to connect to. If you have servers with different cloud providers or several physical offices in which you have servers to manage, you can deploy a worker in each of these locations and connect it to the main controller.<\/p>
\"\"<\/figure>
<\/p>
Installing Vault<\/h2>
1. If you are deploying Vault on an instance that already has Boundary installed, you can simply use the following command in SSH to install it:<\/p>
sudo apt install vault<\/code><\/pre>
    <\/ol>
    2. If, on the other hand, you prefer to deploy Vault on a separate instance, you can deploy an Ubuntu 24.04 Server LTS instance by referring to what is recommended at HashiCorp<\/a>. Then simply follow these steps to install it:<\/p>
    wget -O- https:\/\/apt.releases.hashicorp.com\/gpg | sudo gpg --dearmor -o \/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg\necho \"deb [signed-by=\/usr\/share\/keyrings\/hashicorp-archive-keyring.gpg] https:\/\/apt.releases.hashicorp.com $(lsb_release -cs) main\" | sudo tee \/etc\/apt\/sources.list.d\/hashicorp.list\nsudo apt update && sudo apt install vault<\/code><\/pre>
    3. We will now modify the Vault configuration file. Vault allows you to store information in a variety of ways. In the following example, we’ll simply store it in text files on disk. If you’re thinking of deploying Vault in production, it would be wise to consider using another, more secure method.<\/p>
    sudo vi \/etc\/vault.d\/vault.hcl<\/code><\/pre>
    4. Modify the information in the file to reflect the location of your SSL certificate and the name of your domain:<\/p>
    ui = true\nstorage \"file\" {\n  path = \"\/opt\/vault\/data\"\n}\nlistener \"tcp\" {\n  address       = \"0.0.0.0:8200\"\n  tls_cert_file = \"\/etc\/letsencrypt\/live\/UrlOfYourServer.com\/fullchain.pem\"\n  tls_key_file  = \"\/etc\/letsencrypt\/live\/UrlOfYourServer.com\/privkey.pem\"\n}\napi_addr = \"https:\/\/UrlOfYourServer.com:8200\"<\/code><\/pre>
    5. We can then create a service:<\/p>
    sudo vi \/etc\/systemd\/system\/vault.service<\/code><\/pre>
    6. Add the following information to the file:<\/p>
    [Unit]\nDescription=Vault\n \n[Service]\nType=simple\nUser=root\nExecStart=\/usr\/bin\/vault server -config=\/etc\/vault.d\/vault.hcl\nRestart=always\n \n[Install]\nWantedBy=multi-user.target<\/code><\/pre>
    7. Startup, validate that it starts correctly and activate the service:<\/p>
    sudo systemctl start vault
    sudo systemctl status vault
    sudo systemctl enable vault<\/code><\/pre>
    8. You can now connect to the web page via port 8200 using the dns linked to the SSL certificate you used.<\/p>
    9. The first time you connect, you’ll need to enter a few details. Enter the number 5 in the \u201cKey shares\u201d section, 3 in the \u201cKey threshold\u201d section and download the JSON file that will be created once you press \u201cInitialize\u201d. To unlock Vault after each service restart, you’ll need to enter 3 of the 5 keys generated.<\/p>
    \"\"<\/figure>
    <\/p>
    10. Enter the root token you received in the JSON file to log in once you’ve set 3 of the 5 keys to unlock Vault.<\/p>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    <\/p>
    11. Vault installation is complete.<\/p>
    Installing a Windows Server 2019 Virtual Machine<\/h2>
    Here, we’ll assume that you already have a physical server running Windows Server 2019 in the Hyper-V role. This server is configured inside your company network and already has at least one Windows Server virtual machine configured as a domain controller.<\/p>
    1. Create a virtual machine running Windows Server 2019. You could also use Windows 11 or any other version of Windows you have available.<\/p>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    <\/p>
    2. Install the operating system<\/p>
    \"\"<\/figure>
    \"\"<\/figure>
    <\/p>
    3. Make sure you connect the virtual machine to your domain and enable the RDP connection.<\/p>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    \"\"<\/figure>
    <\/p>
    4. Your virtual machine configuration is now complete.<\/p>
    Create an Ubuntu Server 24.04 LTS Instance at AWS<\/h2>
    1. Deploy an Ubuntu Server 24.04 LTS instance at AWS in the same subnet as your Boundary server, or in a subnet that your Boundary server is ideally able to connect to via the AWS internal network and not via the public network. We’re going to use a t3a.medium instance here, but if you intend to use it as a web server or similar, it’s up to you to use the type of instance that suits you best.<\/p>
    \"\"<\/figure>
    \"\"<\/figure>
    <\/p>
    2. Make sure you use a security rule that allows both your workstations to connect via SSH to this instance and the internal IP address of your Boundary server.<\/p>
    3. Since we only need to have SSH access to this instance, the configuration is completed.<\/p>
      <\/ol>
        <\/ol>","protected":false},"excerpt":{"rendered":"
        Server Configuration for a Zero Trust Solution Steps for configuring servers in a Zero Trust solution Here are the steps for configuring the Zero Trust solution: Boundary Server at AWS 1. Deploy an Ubuntu Server 24.04 LTS instance according to HashiCorp’s recommendations. In the following example, we’ll be deploying an m6i.large instance, which meets the …<\/p>\n
          Server Configuration Zero Trust<\/span> Read More »<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"inline_featured_image":false,"_uag_custom_page_level_css":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"disabled","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","footnotes":""},"class_list":["post-18515","page","type-page","status-publish","hentry"],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"woocommerce_thumbnail":false,"woocommerce_single":false,"woocommerce_gallery_thumbnail":false},"uagb_author_info":{"display_name":"Eleanor Fulton","author_link":"https:\/\/www.directimpactsolutions.com\/en\/author\/eleanor-fulton\/"},"uagb_comment_info":0,"uagb_excerpt":"Server Configuration for a Zero Trust Solution Steps for configuring servers in a Zero Trust solution Here are the steps for configuring the Zero Trust solution: Boundary Server at AWS 1. Deploy an Ubuntu Server 24.04 LTS instance according to HashiCorp’s recommendations. In the following example, we’ll be deploying an m6i.large instance, which meets the…","_links":{"self":[{"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/pages\/18515","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/comments?post=18515"}],"version-history":[{"count":4,"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/pages\/18515\/revisions"}],"predecessor-version":[{"id":18660,"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/pages\/18515\/revisions\/18660"}],"wp:attachment":[{"href":"https:\/\/www.directimpactsolutions.com\/en\/wp-json\/wp\/v2\/media?parent=18515"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}