Skip to main content

Secure lab configuration guide

Amit Cohen avatar
Written by Amit Cohen
Updated this week

1. Introduction

Strigo provides a versatile training and lab environment. However, security in the cloud is a shared responsibility. While Strigo secures the underlying infrastructure and orchestration layer, customers are responsible for the security of the Guest OS (e.g., AMIs, Azure Managed Images, GCP Custom Images) and the Runtime Configuration (Init Scripts) used in their classes.

This guide outlines the best practices for configuring your Strigo labs securely.

2. Secure Image Configuration

When sharing AMIs, Azure Managed Images, or GCP Custom Images with Strigo for use in lab environments, you should adhere to the following hardening standards to prevent unauthorized access.

2.1. Credential Management

  • Disable Root Login: Ensure direct root login via SSH is disabled in the /etc/ssh/sshd_config file.

  • No Hardcoded Secrets: Never bake API keys, passwords, or private SSH keys into the image filesystem.

  • Default Passwords: Change or disable all default OS passwords before creating the image.

  • Temporary Users: Remove any temporary user accounts created during the image build process.

2.2. OS Hardening

  • Patching: Ensure the OS is updated with the latest security patches before sharing the image with Strigo.

  • Minimal Footprint: Uninstall unnecessary services and software to reduce the attack surface.

  • Logging: Ensure standard system logging (e.g., syslog, auth.log) is enabled to capture activity within the lab session.

3. Init Script Security

Strigo allows the execution of initialization (init) scripts upon lab launch. Since these scripts run with elevated privileges, they pose a security risk if misconfigured.

3.1. Secrets Handling

  • Do Not Hardcode Credentials: Never include plain-text passwords, access keys, or database strings directly in the init script text box.

  • Retrieval: If your lab requires credentials, use the init script to fetch them from a secure, ephemeral source or inject them via environment variables where supported.

3.2. Script Integrity

  • External Downloads: If your init script downloads binaries or other scripts (e.g., wget, curl), always verify the integrity of the file using checksums (SHA-256) or ensure the source is a trusted HTTPS endpoint.

    • Bad: curl http://example.com/install.sh | sh

    • Good: curl https://trusted-repo.com/install.sh | sha256sum -c ...

  • Sanitize Inputs: Ensure that any variables used in the script are sanitized to prevent command injection vulnerabilities.

4. Network & Data Privacy

4.1. Lab Isolation

  • Strigo labs are ephemeral. Do not treat the local disk of a lab machine as persistent storage for sensitive data.

  • Instruct students/users to avoid entering Personal Identifiable Information (PII) or real production credentials into the lab environment unless the specific training scenario requires it and appropriate safeguards are in place.

4.2. Egress Traffic

  • Be aware that lab machines may have outbound internet access. Ensure your init scripts and applications do not inadvertently exfiltrate proprietary data to unauthorized external endpoints.

Disclaimer: This guide outlines standard security best practices. Customers retain full responsibility for the configuration, maintenance, and security of their custom images and scripts used on the Strigo platform.

Did this answer your question?