Application Infrastructure AWS

CGRateS 0.10.5 on AWS User Guide

| Product: CGRateS 0.10.5 on Ubuntu 24.04 on AWS

Overview

This guide covers launching and using the CGRateS 0.10.5 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg accounting, HR and finance listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

CGRateS is an open source, carrier grade real time rating, charging and billing engine for telecom, VoIP and any usage metered service. You describe destinations, rates, rating plans, accounts, balances, chargers and attributes as a tariff plan; the engine then prices usage (a call, an SMS, a data session, any custom event), debits prepaid or postpaid balances in real time, stores CDRs and runs actions and thresholds. Applications drive it through a JSON-RPC API; on the instance you can also use the cgr-console command line client and load tariff plans with cgr-loader.

CGRateS has no web interface. Everything in this guide uses curl and cgr-console; point your own application, switch or billing system at the API.

What the cloudimg image adds:

  • Patched binaries. The five CGRateS programs (cgr-engine, cgr-loader, cgr-console, cgr-migrator, cgr-tester) are rebuilt by cloudimg from the upstream v0.10.5 source with Go 1.26.9 and updated Go dependencies (golang.org/x/net, x/crypto, x/text, google.golang.org/grpc, amqp091-go). The upstream package's build carries 44 reachable Go vulnerabilities; govulncheck finds none reachable in the cloudimg build. No CGRateS source line is changed, and the build is reproducible (Step 9).
  • The API is never open on the network. The engine's own listeners have no authentication, so on this image every one of them binds 127.0.0.1. The only way in from outside is nginx on port 443: HTTPS with a certificate generated on your instance, and HTTP Basic Auth with a password generated on your instance, over the whole API. Port 80 redirects to HTTPS, and requests for a host name the instance does not serve are dropped.
  • No default credentials. The Basic Auth password and the Redis password are generated on first boot and written to /root/cgrates-credentials.txt (mode 0600). None is in the image. Redis (the CGRateS DataDB) listens on 127.0.0.1 only and refuses clients without the password.
  • Closed until first boot has finished. The engine starts only after first boot has written the Redis password into its configuration, and nginx starts only after the Basic Auth password and the certificate exist. Before then nothing but SSH listens.
  • Hardened defaults. Every service (the engine, Redis, nginx and the first boot service) is blocked from the instance metadata service; the engine, whose *http_post actions and exporters call URLs you configure, is also blocked from the whole link local range. The AMI requires IMDSv2. nginx passes the engine the configured host name and the client address from the connection, never values a client sends. The engine runs as the unprivileged cgrates user with a systemd sandbox.
  • Ready to rate. The sample tutorial tariff plan is loaded on first boot, so the engine prices a call and returns account balances the moment the instance is up. Replace it with your own plan when you are ready (Step 7).
  • Fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on.

What is on the image: CGRateS 0.10.5 (the signed upstream package cgrates 0.10.5-1~deb12u1 for the service, the cgrates account and the sample tariff plans, with the five programs replaced by the cloudimg rebuild), Redis 7 as the DataDB, CGRateS's internal StorDB (no SQL server is installed), nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent. The Go toolchain and the source are removed after the build, and so are the sample TLS private keys the upstream package carries (they are published in the upstream repository, so they protect nothing); if you enable the engine's own TLS listeners, generate your own key and certificate.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

  • An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet with a route to the internet (or a private route you use for management).
  • A security group that allows TCP 22 (SSH) from your admin network, and TCP 443 (the API) and TCP 80 (redirects to HTTPS) from the networks your applications call from. Never open 2012, 2013, 2080 or 6379; nothing listens on them off the instance anyway.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick CGRateS 0.10.5 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair and a security group as above. Redis keeps the tariff data and accounts on the root volume, so for production give it room to grow (20 GiB or more).

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --block-device-mappings 'DeviceName=/dev/sda1,Ebs={VolumeSize=20,VolumeType=gp3}' \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cgrates}]'

First boot takes well under a minute after the instance is running.

Step 2: Connect to your instance

Version SSH user
CGRateS 0.10.5 on Ubuntu 24.04 ubuntu 
ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot sets the passwords and the certificate, starts the engine, loads the sample tariff plan and then starts nginx:

systemctl is-active redis-server cgrates nginx cgrates-firstboot
sudo test -f /var/lib/cloudimg/cgrates-firstboot.done && echo FIRSTBOOT_DONE

All four units are active and the first boot marker is present:

active
active
active
active
FIRSTBOOT_DONE

Only SSH and nginx listen on network ports. The engine (2012 JSON-RPC, 2013 GOB-RPC, 2080 HTTP JSON-RPC) and Redis listen on the loopback address:

sudo ss -lntp | awk 'NR>1 {print $4, $6}' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | grep -v ':53 ' | sort

0.0.0.0:22 users:(("sshd"),("systemd"))
0.0.0.0:443 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx"))
0.0.0.0:80 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx"))
127.0.0.1:2012 users:(("cgr-engine"))
127.0.0.1:2013 users:(("cgr-engine"))
127.0.0.1:2080 users:(("cgr-engine"))
127.0.0.1:6379 users:(("redis-server"))
[::1]:6379 users:(("redis-server"))
[::]:22 users:(("sshd"),("systemd"))
[::]:443 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx"))
[::]:80 users:(("nginx"),("nginx"),("nginx"),("nginx"),("nginx"))

The engine runs as the unprivileged cgrates user and reports the version:

ps -o user=,args= -C cgr-engine
cgr-engine -version

cgrates  /usr/bin/cgr-engine -config_path=/etc/cgrates
CGRateS@v0.10.5

Step 4: Get your URL and password

sudo cat /root/cgrates-credentials.txt

The file is readable by root only (secret values shown here as placeholders):

# CGRateS 0.10.5 on Ubuntu 24.04 - generated on first boot by cgrates-firstboot.service.
# Every value is UNIQUE to this instance. Store them somewhere safe.

# The JSON-RPC API over HTTPS (nginx, per-instance self-signed certificate) with HTTP Basic Auth:
cgrates.url=https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/jsonrpc
cgrates.basicauth.user=admin
cgrates.basicauth.pass=<CGRATES_BASICAUTH_PASSWORD>

# Redis 7 (the CGRateS DataDB) on 127.0.0.1:6379 only, logical DB 10:
cgrates.redis.pass=<redis-password>

# The engine's own listeners (127.0.0.1:2012 JSON-RPC, :2013 GOB-RPC, :2080 HTTP) are loopback only and have no authentication.
# Verify the instance any time: sudo bash /usr/local/sbin/cgrates-credcheck.sh

cgrates.url uses the instance's public DNS name from the EC2 instance metadata. The certificate also names the public and private IP addresses, so https://<public-ip>/jsonrpc works too. If you stop and start the instance without an Elastic IP, the boot service picks up the new address and issues a new certificate for it. To serve the API under your own DNS name, see Step 8.

Step 5: Call the API

From your workstation a call looks like this (the certificate is self signed until you install your own, so pass -k or, better, download /etc/ssl/cgrates/cgrates.crt and pass --cacert). Keep the password out of your shell history by putting it in a curl config file that only you can read:

printf 'user = "admin:%s"\n' '<CGRATES_BASICAUTH_PASSWORD>' > cgrates-curl.conf && chmod 600 cgrates-curl.conf
curl -k -K cgrates-curl.conf -H 'Content-Type: application/json' \
  -d '{"id":1,"method":"CoreSv1.Ping","params":[{}]}' https://<api-host>/jsonrpc

On the instance itself you can make the same calls through nginx. A request without the password, or with a wrong one, is refused by nginx with 401 before it reaches the engine; with the instance's password the engine answers:

U=$(sudo sed -n 's/^cgrates\.url=//p' /root/cgrates-credentials.txt); H=${U#https://}; H=${H%%/*}
CFG=$(sudo mktemp /run/cgrates-curl.XXXXXX); sudo chown "$(id -u)" "$CFG"
printf 'user = "admin:%s"\n' "$(sudo sed -n 's/^cgrates\.basicauth\.pass=//p' /root/cgrates-credentials.txt)" > "$CFG"
C=(-q -s --cacert /etc/ssl/cgrates/cgrates.crt --resolve "$H:443:127.0.0.1" -H 'Content-Type: application/json')
P='{"id":1,"method":"CoreSv1.Ping","params":[{}]}'
curl "${C[@]}" -o /dev/null -w '%{http_code}\n' -d "$P" "$U"
curl "${C[@]}" -o /dev/null -w '%{http_code}\n' -u admin:not-the-password -d "$P" "$U"
curl "${C[@]}" -K "$CFG" -d "$P" "$U"; echo
sudo rm -f "$CFG"

401
401
{"id":1,"result":"Pong","error":null}

Now ask the engine what it knows. The sample tariff plan created account 1001 in tenant cgrates.org with a monetary balance of 10, and rates calls from 1001 to 1002 at 0.40 for the first minute, then 0.20 per minute. Read the account and price a call of 1 minute 20 seconds:

U=$(sudo sed -n 's/^cgrates\.url=//p' /root/cgrates-credentials.txt); H=${U#https://}; H=${H%%/*}
CFG=$(sudo mktemp /run/cgrates-curl.XXXXXX); sudo chown "$(id -u)" "$CFG"
printf 'user = "admin:%s"\n' "$(sudo sed -n 's/^cgrates\.basicauth\.pass=//p' /root/cgrates-credentials.txt)" > "$CFG"
api() { curl -q -s --cacert /etc/ssl/cgrates/cgrates.crt --resolve "$H:443:127.0.0.1" -K "$CFG" -H 'Content-Type: application/json' -d "$1" "$U"; }
api '{"id":2,"method":"APIerSv1.GetAccount","params":[{"Tenant":"cgrates.org","Account":"1001"}]}' \
  | jq '{id: .result.Id, monetary: [.result.BalanceMap | to_entries[] | select(.key|startswith("*monetary")) | .value[] | {Id, Value}], error}'
api '{"id":3,"method":"APIerSv1.GetCost","params":[{"Tenant":"cgrates.org","Category":"call","Subject":"1001","AnswerTime":"2014-08-04T13:00:00Z","Destination":"1002","Usage":"1m20s"}]}' \
  | jq -c '{cost: .result.Cost, error}'
sudo rm -f "$CFG"

{
  "id": "*out:cgrates.org:1001",
  "monetary": [
    {
      "Id": "test",
      "Value": 10
    }
  ],
  "error": null
}
{"cost":0.6334,"error":null}

On the instance the cgr-console client talks to the engine on 127.0.0.1:2012 directly. This prices a 20 second call (one minute is charged, 0.40 connect plus the first increment):

cgr-console 'cost Category="call" Tenant="cgrates.org" Subject="1001" Destination="1002" AnswerTime="2014-08-04T13:00:00Z" Usage="20s"' | jq -c '{Cost, Usage: ([.Charges[].Increments[].Usage])}'

{"Cost":0.6,"Usage":["0s","1m0s"]}

Every JSON-RPC method of the CGRateS 0.10 API (APIerSv1.*, APIerSv2.*, SessionSv1.*, CDRsV1.* and the rest) is available through https://<api-host>/jsonrpc; the WebSocket endpoint /ws sits behind the same Basic Auth. See the CGRateS documentation at cgrates.readthedocs.io.

Step 6: Verify the instance

cgrates-credcheck.sh checks the network exposure, Redis authentication, the HTTPS front door (refused without and with a wrong password, the engine answering with the right one), account 1001 and a rated call:

sudo bash /usr/local/sbin/cgrates-credcheck.sh

OK

Step 7: Load your own tariff plan

A tariff plan is a directory of CSV files (Destinations.csv, Rates.csv, DestinationRates.csv, RatingPlans.csv, RatingProfiles.csv, Actions.csv, ActionPlans.csv, AccountActions.csv, Chargers.csv, Attributes.csv and so on). The sample plans that ship with CGRateS are a good starting point:

ls /usr/share/cgrates/tariffplans/tutorial

AccountActions.csv
ActionPlans.csv
Actions.csv
Attributes.csv
Chargers.csv
DestinationRates.csv
Destinations.csv
Filters.csv
README.md
Rates.csv
RatingPlans.csv
RatingProfiles.csv
Resources.csv
Stats.csv
Suppliers.csv
Thresholds.csv

Copy one into a directory you own, edit it, then load it. cgr-loader reads the Redis connection and password from the engine configuration, so no password goes on the command line, and it tells the running engine to reload its caches:

sudo cp -r /usr/share/cgrates/tariffplans/tutorial /srv/my-tariffplan
sudo cgr-loader -config_path=/etc/cgrates -path=/srv/my-tariffplan -verbose

The DataDB is Redis logical database 10. The StorDB (CDRs and tariff plans kept in the database rather than in CSV files) is CGRateS's internal store; to archive CDRs in MySQL or PostgreSQL, install the database server on localhost or point at Amazon RDS, change stor_db in /etc/cgrates/cgrates.json and restart the engine (sudo systemctl restart cgrates).

The engine's S3 and SQS exporters cannot use an EC2 instance role on this image, because every service is blocked from the instance metadata service. Give them an access key in the exporter configuration instead (store it in /etc/cgrates/cgrates.json, which only root and the cgrates user can read).

Step 8: Your own DNS name and certificate

Point a DNS record at the instance (an Elastic IP keeps the address stable), then set the name the API is served as. This mints a new self signed certificate for the name, updates nginx and cgrates.url in /root/cgrates-credentials.txt, and keeps the name across reboots:

sudo cgrates-set-hostname <your-domain>

To use a certificate from a public or internal certificate authority instead, copy it over the generated pair and reload nginx (running cgrates-set-hostname again replaces it with a self signed one):

sudo install -m 0644 <your-domain>.crt /etc/ssl/cgrates/cgrates.crt
sudo install -m 0600 <your-domain>.key /etc/ssl/cgrates/cgrates.key
sudo nginx -t && sudo systemctl reload nginx

Step 9: Security checks

Plain HTTP redirects to HTTPS on the configured name, and a request for any other host name is dropped without an answer (nginx closes the connection, shown as 000):

U=$(sudo sed -n 's/^cgrates\.url=//p' /root/cgrates-credentials.txt); H=${U#https://}; H=${H%%/*}
curl -q -s -o /dev/null -w 'http:// -> %{http_code} %{redirect_url}\n' --resolve "$H:80:127.0.0.1" "http://$H/jsonrpc"
curl -q -s -o /dev/null -w 'unknown host -> %{http_code}\n' -H 'Host: example.com' http://127.0.0.1/ || true

http:// -> 301 https://ec2-<public-ip-dashed>.compute-1.amazonaws.com/jsonrpc
unknown host -> 000

The certificate was generated on this instance and names its own addresses:

U=$(sudo sed -n 's/^cgrates\.url=//p' /root/cgrates-credentials.txt); H=${U#https://}; H=${H%%/*}
echo | openssl s_client -connect 127.0.0.1:443 -servername "$H" 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

subject=CN = ec2-<public-ip-dashed>.compute-1.amazonaws.com, O = cloudimg
X509v3 Subject Alternative Name: 
    DNS:ec2-<public-ip-dashed>.compute-1.amazonaws.com, IP Address:<public-ip>, IP Address:<private-ip>, IP Address:127.0.0.1, DNS:localhost

None of the services can reach the instance metadata service. The engine and the first boot service are also blocked from the whole IPv4 and IPv6 link local ranges (systemd shows 169.254.169.254/32 folded into 169.254.0.0/16), so an *http_post action or an exporter URL can never reach instance metadata:

systemctl show cgrates redis-server nginx cgrates-firstboot -p Id -p IPAddressDeny

IPAddressDeny=169.254.0.0/16 fe80::/10 fd00:ec2::254/128 168.63.129.16/32
Id=cgrates.service

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
Id=redis-server.service

IPAddressDeny=fd00:ec2::254/128 169.254.169.254/32 168.63.129.16/32
Id=nginx.service

IPAddressDeny=fe80::/10 fd00:ec2::254/128 168.63.129.16/32 169.254.0.0/16
Id=cgrates-firstboot.service

Actions and exporters can still reach addresses in your VPC, which is usually what you want. To stop the engine reaching private ranges too, add them in a drop-in, for example IPAddressDeny=10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 in /etc/systemd/system/cgrates.service.d/60-private.conf, then sudo systemctl daemon-reload and sudo systemctl restart cgrates.

Every engine listener is pinned to the loopback address (the TLS variants are only opened if you configure a server certificate), and nginx guards the whole API with Basic Auth, hands the engine the configured host name and the client address from the connection, and never forwards the client's Authorization header:

jq .listen /etc/cgrates/cgrates.json
grep -E 'auth_basic|proxy_pass|proxy_set_header (Host|X-Forwarded-For|X-Real-IP|X-Forwarded-Host|Authorization) ' /etc/nginx/sites-available/cloudimg-cgrates

{
  "rpc_json": "127.0.0.1:2012",
  "rpc_gob": "127.0.0.1:2013",
  "http": "127.0.0.1:2080",
  "rpc_json_tls": "127.0.0.1:2022",
  "rpc_gob_tls": "127.0.0.1:2023",
  "http_tls": "127.0.0.1:2280"
}
    auth_basic "CGRateS API";
    auth_basic_user_file /etc/nginx/cgrates.htpasswd;
        proxy_pass http://127.0.0.1:2080;
        proxy_set_header Host $cgrates_host;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host "";
        proxy_set_header Authorization "";

Because the loopback listeners have no authentication, anyone with a shell on the instance can drive the engine. Keep SSH access to the people who administer billing, and never change listen to a non loopback address: use nginx for remote access.

The secrets are only in files root (and, for the engine configuration, the cgrates user; for the password hash, nginx) can read:

sudo stat -c '%A %U %G %n' /root/cgrates-credentials.txt /etc/cgrates/cgrates.json /etc/nginx/cgrates.htpasswd /etc/ssl/cgrates/cgrates.key

-rw------- root root /root/cgrates-credentials.txt
-rw-r----- root cgrates /etc/cgrates/cgrates.json
-rw-r----- root www-data /etc/nginx/cgrates.htpasswd
-rw------- root root /etc/ssl/cgrates/cgrates.key

The build records exactly what is on the image. The packaged upstream programs are diverted with dpkg-divert, so a package reinstall can never put them back over the rebuild:

cat /usr/share/doc/cgrates-cloudimg/BUILD_VERSIONS
dpkg-divert --list '/usr/bin/cgr-*' | sort

cgrates=v0.10.5
cgrates-commit=0674f9eb51452706095d0b54746666ddd835b902
cgrates-deb=0.10.5-1~deb12u1
go-toolchain=go1.26.9
build-flags=CGO_ENABLED=0 GOOS=linux GOARCH=amd64 -trimpath -buildvcs=false
dependency-bumps=golang.org/x/net@v0.60.0 golang.org/x/crypto@v0.57.0 golang.org/x/text@v0.42.0 google.golang.org/grpc@v1.83.2 github.com/rabbitmq/amqp091-go@v1.14.0
go.mod.sha256=5adacaee21bb06efb46211767e2afc03544106e0d7e1ffa8bfb1a63cf0a6dd98
go.sum.sha256=24daddd2f95de37262e18fa0e0de5fdc054f73a95400858dba8667244fa678c9
cgr-engine.sha256=f22a18493f1c415d7e27cf2bde63e1fb12e17196d6fb17df6aef4b3cfe4d9b32
cgr-loader.sha256=6a6e225d09f78729ec9cb0ca553ac8ec50dfa7b956fb7ef6a6d38b502d8b3bd4
cgr-console.sha256=53d2449994dd835f4aca34add1f4c9dea9feace152d1ab4c46c2cdbe1d87d2e5
cgr-migrator.sha256=4445c75b37743d9e9d8b75e12bbb670949dd2ac34020c13ef1d775df4d112fb2
cgr-tester.sha256=b1218e9726627f088cd0d9749c335086a65c828384f0e08b072d5b42ff10166f
redis-server=5:7.0.15-1ubuntu0.24.04.5
nginx=1.24.0-2ubuntu7.18
local diversion of /usr/bin/cgr-console to /usr/bin/cgr-console.cgrates-deb
local diversion of /usr/bin/cgr-engine to /usr/bin/cgr-engine.cgrates-deb
local diversion of /usr/bin/cgr-loader to /usr/bin/cgr-loader.cgrates-deb
local diversion of /usr/bin/cgr-migrator to /usr/bin/cgr-migrator.cgrates-deb
local diversion of /usr/bin/cgr-tester to /usr/bin/cgr-tester.cgrates-deb

Step 10: Changing passwords

  • Basic Auth password: generate a new password and write its hash without putting it on a command line, then reload nginx, and update cgrates.basicauth.pass in /root/cgrates-credentials.txt and your applications:
NEW=$(openssl rand -base64 48 | tr -dc 'A-Za-z0-9' | cut -c1-32)
printf '%s\n' "$NEW" | openssl passwd -6 -stdin | sed 's/^/admin:/' | sudo tee /etc/nginx/cgrates.htpasswd >/dev/null
sudo systemctl reload nginx
  • Redis password: change requirepass in /etc/redis/redis.conf and data_db.db_password in /etc/cgrates/cgrates.json to the same new value, update cgrates.redis.pass in the credentials file, then sudo systemctl restart redis-server cgrates.
  • More users: add one user:hash line per user to /etc/nginx/cgrates.htpasswd (hash made the same way) and reload nginx.

Step 11: Backup and maintenance

The tariff plans, accounts and balances live in Redis logical database 10 (/var/lib/redis). The simplest backup is an EBS snapshot of the root volume. For a point in time Redis dump, run SAVE and copy /var/lib/redis/dump.rdb:

sudo bash -c 'REDISCLI_AUTH=$(sed -n "s/^cgrates\.redis\.pass=//p" /root/cgrates-credentials.txt) redis-cli SAVE'
sudo cp /var/lib/redis/dump.rdb <backup-dir>/cgrates-redis-$(date +%F).rdb

Keep your tariff plan CSV files in version control too: cgr-loader can rebuild the DataDB from them at any time. Operating system security updates install automatically; run sudo apt-get update && sudo apt-get upgrade to apply everything else. The cgrates package is held, so an upgrade never replaces the rebuilt programs.

Component Path
Programs (cloudimg rebuild) /usr/bin/cgr-engine, cgr-loader, cgr-console, cgr-migrator, cgr-tester
Engine configuration /etc/cgrates/cgrates.json (mode 0640)
Service cgrates.service (drop-ins in /etc/systemd/system/cgrates.service.d/)
DataDB Redis 7, logical database 10 (/var/lib/redis)
Sample tariff plans /usr/share/cgrates/tariffplans/
nginx site /etc/nginx/sites-available/cloudimg-cgrates
Basic Auth users /etc/nginx/cgrates.htpasswd (mode 0640)
Certificate and key /etc/ssl/cgrates/
Boot service /usr/local/sbin/cgrates-firstboot.sh
Host name helper /usr/local/sbin/cgrates-set-hostname
Self check /usr/local/sbin/cgrates-credcheck.sh
Credentials /root/cgrates-credentials.txt (mode 0600)
Licence, source notice and build record /usr/share/doc/cgrates-cloudimg/

Step 12: Security recommendations

  • Allow port 22 from your admin network only, and ports 80 and 443 only from the networks your applications call from.
  • Use your own DNS name and a certificate your clients trust (Step 8), and pin it in your applications.
  • Give each application its own Basic Auth user (Step 10), and rotate a password if it may have leaked.
  • Keep the operating system patched, and snapshot the root volume regularly.

Support and licensing

CGRateS is free software under the GNU Affero General Public License version 3; there is no per user or per CPU licence fee. The licence text and the corresponding source notice are on the instance in /usr/share/doc/cgrates-cloudimg/ (LICENSE.txt, SOURCE.md). cloudimg builds the CGRateS programs from the unmodified upstream source at tag v0.10.5 (github.com/cgrates/cgrates, commit 0674f9eb5); the only change is the Go dependency update in go-mod-go-sum.diff in the same directory, and SOURCE.md explains how to rebuild the identical binaries. The AMI price covers cloudimg's hardening, first boot setup and support.

CGRateS is a trademark of ITsysCOM GmbH. This image is produced by cloudimg and is not affiliated with, endorsed by, or sponsored by ITsysCOM GmbH.

  • Email: support@cloudimg.co.uk
  • Website: https://www.cloudimg.co.uk
  • Support: 24/7, with a 24 hour response SLA