Skip to main content

Security

Security is a top priority at Molnett. We provide features and follow practices to help you build and run secure applications on our platform.

This page complements the broader Security and Compliance overview by focusing on platform-specific security features you can leverage.

Secrets Management​

Properly managing sensitive information like API keys, database passwords, and other credentials is crucial. Molnett provides a secure way to store and use secrets within your services.

Defining Secrets in molnett.yaml: You reference secrets in your container definitions. The value you provide is the name of the secret as stored in Molnett, not the secret itself.

# In your molnett.yaml
containers:
  - name: my-app
    image: my-image
    secrets:
      - key: DATABASE_PASSWORD # This ENV VAR will be set in your container
        value: "prod-db-password" # This is the NAME of the secret stored in Molnett
      - key: PAYMENT_API_KEY
        value: "payment-gateway-key"

Managing Secrets with molnctl: You use molnctl to create, update, list, and delete secrets within a specific project and environment.

  • Create or Update a Secret:

    # Molnctl will prompt you to securely enter the secret value
    molnctl create secret prod-db-password 

    # Or provide it via stdin (use with caution, especially in scripts)
    # echo "mySuperSecretValue" | molnctl create secret prod-db-password --value-stdin

    Note: Secrets are typically scoped to a Molnett Project and Environment.

  • List Secrets:

    molnctl get secrets

  • Delete a Secret:

    molnctl delete secret prod-db-password

How it Works: When your service starts, Molnett securely injects the actual secret values as environment variables into your containers, corresponding to the key you defined in the secrets section of your molnett.yaml.

Best Practices for Secrets:

  • Use distinct secrets for different environments (e.g., dev-db-password, prod-db-password).
  • Grant minimal necessary permissions for accessing secrets (covered under IAM/Access Control if applicable).
  • Rotate secrets regularly.

Environment Variables​

For non-sensitive configuration, you can use regular environment variables defined directly in your molnett.yaml:

# In your molnett.yaml
containers:
  - name: my-app
    image: my-image
    environment:
      - key: APP_ENVIRONMENT
        value: "production"
      - key: LOG_LEVEL
        value: "info"

These are suitable for configuration that isn't secret, like application modes, feature flags, or service endpoints.

Network Security​

  • HTTPS by Default: All traffic to published service ports via Molnett-generated URLs or configured custom domains is automatically served over HTTPS.
  • Internal Network: By default, containers within the same service can communicate with each other. Communication between different services within the same project/environment is also typically allowed over an internal network. Access from outside your project to non-published ports is blocked.
  • Firewalls/Network Policies (Future): (Mention plans for more granular network controls if applicable, e.g., ability to define explicit allow/deny rules between services).

Container Security​

  • Image Scanning (User Responsibility/Integration): While Molnett securely runs your containers, it's your responsibility to ensure your container images are free from vulnerabilities. We recommend integrating image scanning tools (e.g., Trivy, Snyk, Docker Scout) into your CI/CD pipeline before pushing images to your registry.
  • Principle of Least Privilege: Design your applications and container entrypoints to run with the minimum necessary permissions. Avoid running processes as root inside containers if possible.

Access Control (IAM - Identity and Access Management)​

(This section to be detailed based on Molnett's IAM capabilities.)

Molnett likely provides mechanisms to control who can access your projects, environments, and services, and what actions they can perform.

  • User Roles & Permissions: (e.g., Admin, Developer, Viewer roles for projects).
  • Service Accounts (Potentially): For programmatic access from CI/CD systems or other tools.
  • Audit Logs (Potentially): Logging of actions performed via molnctl or the Web UI for security auditing.

Data Security​

  • EU-Centric: As mentioned in Security and Compliance, Molnett processes and stores data within European borders.
  • Encryption at Rest & In Transit: (Reiterate if specific platform components like secret storage or future managed databases have encryption by default).

Building secure applications is a shared responsibility. Molnett provides a secure foundation and tools, while you are responsible for the security of your application code, dependencies, and image contents.