Security

Passwords

The Artemis configuration files contain a few default passwords and secrets that have to be overridden in your own configuration files or via environment variables (Spring relaxed binding).

artemis:
    user-management:
        internal-admin:
            username: "artemis-admin"
            # can be changed later, Artemis will update the password in the database
            # and connected systems on the next start
            password: "artemis-admin"
    version-control: # only required if using Integrated code lifecycle. In a distributed setup, this needs to be configured for localvc nodes and buildagent nodes
        build-agent-git-username: "buildagent_user" # Required for https access to localvc
        build-agent-git-password: "buildagent_password" # Required for https access to localvc. You can otherwise use an ssh key
jhipster:
    security:
        authentication:
            jwt:
                # used to sign the JWT tokens for user authentication
                # can be changed later, will require all users to log in again
                #
                # encoded using Base64 (you can use `echo 'secret-key'|base64` on your command line)
                base64-secret: ""
    registry:
        password: "change-me"  # only for distributed setups with multiple Artemis instances

spring:
    prometheus:
        # if Prometheus monitoring is enabled: a comma-separated list of
        # IPs that are allowed to access the metrics endpoint
        monitoring-ip: "127.0.0.1"
    websocket:
        broker:
            username: "guest"  # only for distributed setups
            password: "guest"  # only for distributed setups

Note

The usernames/passwords for external systems (GitLab, Jenkins, …) are not listed here, since the general setup documentation describes how to set up those systems. Without replacing the default values, the connection to them will not work.

Note

Ensure restrictive access to the configuration files, so that access is only possible for the system account that runs Artemis and administrators.

SSH Access

To allow users to clone their programming exercises via SSH in the integrated code lifecycle setup, SSH must be configured correctly on the server.

Follow the next steps to create and manage SSH key pairs, distribute them across multiple nodes via Ansible, configure the system to use these keys, and adapt Nginx to enable SSH routing.

Creating Key Pairs for Each Supported Algorithm

Generate key pairs for the supported algorithms (RSA, ECDSA, and Ed25519) using the ssh-keygen command. Here’s how you can do it:

# Generate RSA key pair
ssh-keygen -t rsa -b 4096 -f ~/artemis_ssh/id_rsa

# Generate Ed25519 key pair
ssh-keygen -t ed25519 -f ~/artemis_ssh/id_ed25519

Make sure the keys have the standard name for the according key type. E.g. id_rsa for RSA.

Adding Key Pairs to VM via Ansible

Use Ansible to distribute the generated key pairs to all VMs in your infrastructure. Here’s an example Ansible playbook to achieve this:

- name: Distribute SSH keys to VMs
  hosts: all
  vars:
    key_dir: "/path/to/keys"
  tasks:
    - name: Copy RSA key pair to VM
      copy:
        src: "{{ key_dir }}/id_rsa"
        dest: "~/.ssh/id_rsa"
        mode: '0600'

    - name: Copy RSA public key to VM
      copy:
        src: "{{ key_dir }}/id_rsa.pub"
        dest: "~/.ssh/id_rsa.pub"
        mode: '0644'

Configuring System to Use Keys

Ensure the configuration variables point to the folder containing the keys. You can set this in your Ansible playbook or configuration management tool.

In a multinode setup, it is crucial that all nodes use the same set of keys to ensure hosts can communicate with all nodes correctly. Ensure the key distribution playbook is applied to all nodes in the cluster.

For Artemis to find the key set artemis.version-control.ssh-host-key-path to the path where you stored the keys.

Adapting Nginx to Enable SSH Routing

To enable SSH routing through Nginx, you can set up an SSH proxy.

Configure Nginx to proxy HTTPS traffic on port 443 and SSH traffic on port 7921.

http {
    server {
        listen 443 ssl;
        server_name yourdomain.com;

        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

stream {
    server {
        listen 7921;
        proxy_pass 127.0.0.1:7921;
    }
}

Restart Nginx:

sudo systemctl restart nginx

By following these steps, you ensure that your key pairs are properly generated and distributed across all nodes, the configuration is set up to point to the folder with the keys, and Nginx is adapted to handle SSH routing through a proxy setup.