Skip to content

epomatti/azure-linux-security

Repository files navigation

Azure Linux security

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

Protecting local secrets

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

Strong disk encryption

There are different options for disk encryption, as in this article. There is a comparison table as well.

System user permissions

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.

Encryption

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)

Security events monitoring (SIEM)

A SIEM-like approach can be used to monitor these directories that react to user actions that could potentially compromise the secrets.