Security

Last Updated 8/30/2022, 7:52:38 AM UTC
About 7 min read

ℹ️ Polaris distribution repo public key

# Trust

How can you trust that a file that you are about to use has been provided by someone without malicious designs? Consider for example a file that contains SQL code that you want to pass to the sql-collector plugin in order to gather some useful metrics - how do you know that it is safe to use this file? How about the sql-collector plugin itself - how can you trust that the initial version you used or any subsequent updates can be trusted?

We establish trust through cryptographic signatures by only using files that have been signed by someone we trust.

# Set up your signing keys

We use cryptographic keys to sign configuration files. You can use a key management service such as OCI Vault to manage your signing keys or you can bring your own keys to use with polaris.

Supported key types are:

RSA (PKCS#1 v1.5)
ECDSA

Once you've setup your signing keys, get hold of the public key parts and point to them in ~/.myrmex/trusted_keys.yaml. For example:

keys:
  - name: a_signing_key_name                                    # key name
    pem_path: /home/some_user/.myrmex/a_signing_key.pem         # path to public key PEM 
  - name: another_signing_key_name                              # key name
    pem_path: /home/some_user/.myrmex/another_signing_key.pem   # path to public key PEM

If you are using a KMS service you will also need to configure the API parameters to the service. You do this by setting up file ~/.myrmex/iaas_config.yaml. For example, if you are using OCI Vault:

oci_config_path: /path/to/oci/api/configuration/file  # defaults to $HOME/.oci/config if empty
kms:
    signing_keys:
      a_signing_key:
          id: key OCID
          crypto_endpoint: your OCI crypto endpoint URL

ℹ️ checkout the Appendix for how to setup OCI Vault

# Sign your configurations

When you create or change configurations in git you can sign the whole of the polaris assets directory using the myrmex CLI

if using a KMS (e.g. OCI):

myrmex integrity sign-oci-kms \
  --key [your key name from iaas_config.yaml] \
  [path to your polaris assets dir in git]

if using your own key

myrmex integrity sign-local \
  --key [path to private key PEM to sign with]
  [path to your polaris assets dir in git]

The CLI will report all changed files that will be signed and ask you to confirm these changes before signing. If you see changes that you do not recognize do not proceed until you have established that they can be trusted. Once signed add, commit and push your changes.

# Verify configurations integrity

To check the current status for your configurations integrity:

myrmex integrity verify \
  [path to your polaris assets dir in git]

This will report any configuration changes that have not been signed.

# Securing Polaris Git Assets

Polaris by default requires that git assets have been signed before they can be accepted. Set the public keys that polaris will use to verify git assets in myrmex-sd.conf

[catalog]
  # path to configuration file for public keys which are trusted to verify git assets
  trusted_keys_path = "/opt/polaris/.myrmex/trusted_keys.yaml"

To disable asset verification for a git repo, update the repo configuration in myrmex-sd.conf like below:

  [[catalog.git_repo]]
    # the repo that you want to skip verification
    url                  = "https://some/repo.git"
    disable_verification = true

# Git Access Control

# Local file system

Only users that can login to the server hosting your git repos
Users must be members of the group of the git repo directory. Does not need be their primary group

git clone ${MYRMEX_DATA}/<repo-name>.git

# SSH

Users must be members of the group of the git repo directory as above and must have an ssh key known to the server hosting the git repo.

git clone ssh://<username>@<git-hostname>/${MYRMEX_DATA}/<repo-name>.git

# HTTPS

Via HTTP basic access authentication over TLS
Add self signed TLS cert PEMs to a file and let git know where to find this file

mkdir -p ~/.git-certs
cat server.crt >> ~/.git-certs/certs.pem
git config --global http.sslCAInfo $HOME/.git-certs/certs.pem
git clone https://<ht_user>@${HTTP_SERVER_DNS_NAME}:${HTTPS_PORT}/git/<repo-name>.git

# HTTP

From localhost only
Via HTTP basic access authentication

git clone http://<ht_user>@localhost:${HTTP_PORT}/git/<repo-name>.git

# Git Asset vetting

You may choose to mirror the Arisant distribution repo if you are inside a network that cannot access https://github.com/arisant/myrmex-dist.git or you do not want the system to automatically fetch updates from this repo.

# Setup your mirrored repo

Initialize a bare repo on a node inside your network that the myrmex-sd server can access it.

mkdir /data/git/repos/myrmex-dist-mirror.git
cd /data/git/repos/myrmex-dist-mirror.git
git init --bare
git config core.sharedRepository group

# Clone the Arisant distribution repo

On a network node that has access to the internet and your internal network clone the Arisant distribution repo

git clone --mirror https://github.com/arisant/myrmex-dist.git

Mirror to your internal repo:

cd myrmex-dist.git
git push --mirror https://[your-git-host]:[port]/git/myrmex-dist-mirror.git

Update your mirrored git with changes from the Arisant repo:

cd myrmex-dist.git
git fetch -p origin
git push --mirror https://[your-git-host]:[port]/git/myrmex-dist-mirror.git

If you want to vet the content from the Arisant repo before pushing to your internal repo:

cd myrmex-dist.git
git fetch -p origin
cd ..
git clone myrmex-dist.git
### updated content now in directory myrmex-dist
### once it passes your vetting process do:
cd ../myrmex-dist.git
git push --mirror http://[your-git-host]:[port]/git/myrmex-dist-mirror.git

Once you've cloned myrmex-dist.git you can pull subsequent changes for vetting like so:

cd myrmex-dist.git
git fetch -p origin
cd ../myrmex-dist
git pull
## vet your changes in this directory and then:
cd ../myrmex-dist.git
git push --mirror http://[your-git-host]:[port]/git/myrmex-dist-mirror.git

# Appendix

# Setup an OCI Vault signing key

# Create the signing key

Identity & Security> Vaults
Create or Open a vault
Create Key
- Compartment: chose any compartment that makes sense
- Protection Mode: HSM
- Key Shape Algorithm RSA
Create OCI Group to allow users to sign with this key
- Identity Groups
- Create group with meaningful name e.g. ms-signers
- Add OCI users
Create Policy to allow signing with this key
- Identity > Policies > Create Policy
- Give it a meaningful name
- Set compartment to same compartment as your key
- Add policy statement Allow group <your_oci_group_name_above> to use keys in compartment <your_compartment_name> where target.key.id='<your_key_OCID>'
Create Identity Federation Group to allow federated users to sign with this key
- Identity > Federation > your idP > Groups
- Create a group with meaningful name e.g. KMS Sign
- Map group to OCI Group above
- Add federated users to group

# Create API key pair

Generate API key pair and add to your account API Keys

openssl genrsa -out ~/.oci/oci_api_key.pem -aes128 2048
chmod go-rwx ~/.oci/oci_api_key.pem
openssl rsa -pubout -in ~/.oci/oci_api_key.pem -out ~/.oci/oci_api_key_public.pem

# Myrmex OCI Vault Configuration

Create OCI API configuration file:

API Keys > your key > View Configuration file > Copy
Paste into ~/.oci/config
Set key_file param to path of your private key file

create iass.yaml

oci_config_path: path to oci config or defaults to $HOME/.oci/config
kms:
  signing_keys:
    a_key_name:
       id: your signing key > Copy OCID
       crypto_endpoint: your vault > Cryptographic Endpoint > Copy

← Data Blending Working with SQL sources →