Note
Make sure you enable host-based encryption in the subscription before you start
Generate the .auto.tfvars
from the template:
cp config/template.tfvars
Set your public IP address in the allowed_source_address_prefixes
variable using CIDR notation:
# allowed_source_address_prefixes = ["1.2.3.4/32"]
curl ifconfig.io/ip
Create a temporary key for the Virtual Machine:
mkdir keys && ssh-keygen -f keys/temp_rsa
Deploy the resources:
terraform init
terraform apply -auto-approve
Connect to the VM and mount the data disk.
Important
Make sure mount is persistent after reboots
If storing secrets locally in disk is unavoidable, extra protections should be provisioned.
Important
When implementing advanced features, check limits and restrictions that might apply
- Tunneling from the origin to destination
- Restrict origin addresses at the destination (IP, SNI)
- Proper file permissions setup
- Strong admin user access control
- Disk encryption with customer-managed key (CMK)
- Platform-specific encryption technology (Azure Encryption-at-Host, ADE)
- Use HSM
Complex approaches:
- Use a custom kernel module to change root access permissions (SELinux, AppArmor)
- Security events monitoring (SIEM)
- Auditing
Other approaches (not as effective, side effects):
- Encrypted locally but with password in the same filesystem (chicken and the egg problem)
- Create the secret files with a hidden prefix (".")
- Use a random name for the files
There are different options for disk encryption, as in this article. There is a comparison table as well.
Following this threat, there are some ways of increasing the security of local secrets.
Login as super user:
sudo su -
Create the system user with the -r
option (manual pages):
# A system user does not have a password, a home dir, and is unable to login
useradd -r litapp
Create the appliation directory and assign ownership:
mkdir /opt/litapp
chown -R litapp /opt/litapp
Switch to the litapp
user:
sudo -u litapp -s
Enter the directory and create the sample key:
cd /opt/litapp
ssh-keygen -f sample_rsa
Once the sample key is created, restrict the access to the files to read only:
Tip
The execute
permission is required to cd into the directory
# Owner read-only to files
chmod 400 /opt/litapp/sample_rsa
chmod 400 /opt/litapp/sample_rsa.pub
# Owner read and execute for the directory
chmod 500 /opt/litapp
For advanced protection for the root user, a custom kernel might have to be written. Modules such as with SELinux or AppArmor.
Key Vaults might have limited capabilities for keys.
Important
This project uses a Key Vault with Private Link to test CMK scenarios (in case there are network restrictions)
A SIEM-like approach can be used to monitor these directories that react to user actions that could potentially compromise the secrets.