On RSA keys for OCI API access🔑

Just don’t use the same RSA key over and over, between projects, tenants, users … In any form : api AuthN keys or ssh keys. Please. Just don’t.

That being said, security principals needs to be easy to implement, with minimal efforts. If not, unpleasant shortcuts will be taken at some point.

Ideally, you should always manage keys with a vault, either HSM backed or with a software secret management solution.

However, it is not always possible to have the infrastructure components to manage secrets. In this case, following these principles is the bare minimum:
1️⃣ Generate a new key for each purpose,
2️⃣ Do not repurpose 🙂,
3️⃣ Make the key as transient as possible,
4️⃣ Ideally, each key should be a disposable.

To implement these four principles, we need solve two problems:

  • easily generate new key pairs,
  • easily distribute/update public keys.

Generating rsa key pairs

Generating ssh key pairs is relatively easy with openssl.

The example below shows how to generate a private key in .pem format. It is just 3 commands to have a usable private and public key:

# generate rsa private key
openssl genrsa -out key.pem 2048
#adjust filesystem rights
chmod go-rwx key.pem
#extract public key for distribution
openssl rsa -pubout -in key.pem -out key_public.pem 

You have now two files:

  • key.pem: your private key, which needs to be protected,
  • key_public.pem: the corresponding public key, which needs to be distributed on remote systems when access will be granted.

This is the format used for OCI API keys. More information can be found here.

For ssh usage, you need to use ssh-keygen to have your keys in the correct format for ssh. More information can be found here.

Distributing public keys

The goal is to upload the public key to an OCI user profile, in a programatic way. This requires to use one of the available sdk options (oci cli, terraform, etc …), so you will obviously need an initial account with access to API already configured.

We will automate the configuration of any subsequent accounts.

Using OCI CLI

Once you have generated your key pair, it take one command to update an OCI IAM User with this key:
oci iam user api-key upload --user-id <your-user-ocid> --key-file <key_public.pem>

The following Gist contains a shell script that generates a key pair and update an oci user:
https://gist.github.com/kral2/dd20fa59e5186c15e92439f539ea471e

You will need to have oci cli already configured on your system, and configure the USER_OCID variable.

Idempotency?

  • The key pair will be generated on first run and not overwritten on subsequent execution,
  • OCI API will detect if a key with identical fingerprint is already present for that user and will return an error.

Using Terraform

This Gist allows to manage the API key of a user using a Terraform configuration :
https://gist.github.com/kral2/737b0617c1f1dfa12ab606918ef1c698

You will need to first generate a key pair with the generate_RSA-key.sh shell script, then apply the terraform configuration after you have configured the terraform.tfvars file with your information tenant information.

Terraform configurations are idempotent by default. The advantages over the oci cli method are the tear-down and how updates to key pairs are handled:

  • if a new key is generated, terraform will reflect the change,
  • you can easily suppress the api key when you are done with a terraform destroy.
Tagged with: , ,

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.