How to harden your deployment

doc
1

See also: Juju security

Juju ships with sensible security defaults. However, security doesn’t stop there.

Harden the cloud

Use a private cloud.

See more: List of supported clouds

If you want to go one step further, take your cloud (and the entire deployment) offline.

See more: How to take your deployment offline

Harden the client and the agent binaries

When you install Juju (= the juju CLI client + the Juju agent binaries) on Linux, you’re installing it from a strictly confined snap. Make sure to keep this snap up to date.

See more: Snapcraft | Snap confinement, Install and manage the client, Roadmap & Releases

Harden the controller(s)

In a typical Juju workflow you allow your client to read your locally stored cloud credentials, then copy them to the controller, so that the controller can use them to authenticate with the cloud. However, for some clouds Juju now supports a workflow where your (client and) controller doesn’t need to know your credentials directly – you can just supply an instance profile (AWS) or a managed identity (Azure). One way to harden your controller is to take advantage of this workflow.

See more: Bootstrap a controller, AWS and Juju, Azure and Juju

(Like all the cloud resources provisioned through Juju,) the cloud resource(s) (machines or containers) that a controller is deployed on by default run the latest Ubuntu LTS. This Ubuntu is not CIS- and DISA-STIG-compliant (see more: Ubuntu | The Ubuntu Security Guide). However, it is by default behind a firewall, inside a VPC, with only the following three ports opened – as well as hardened (through security groups) – by default:

When a controller deploys a charm, all the traffic between the controller and the resulting application unit agent(s) is TLS-encrypted (each agent starts out with a CA certificate from the controller and, when they connect to the controller, they get another certificate that is then signed by the preshared CA certificate). In addition to that, every unit agent authenticates itself with the controller using a password.

See more: Wikipedia | TLS

Compute resources (machines or containers) for a controller can be provisioned using constraints and spaces, to minimise over-provisioning and restrict access.

See more: Manage controllers

Harden the user(s)

When you bootstrap a controller into a cloud, you automatically become a user with controller admin access. Make sure to change your password, and choose a strong password.

Also, when you create other users (whether human or for an application), take advantage of Juju’s granular access levels to grant access to clouds, controllers, models, or application offers only as needed. Revoke or remove any users that are no longer needed.

See more: User, User access levels, Manage users

If you want relationship-based access control (ReBAC), check out JAAS.

See more: JAAS | Authorisation

Harden the model(s)

Within a single controller, living on a particular cloud, you can have multiple users, each of which can have different models (i.e., workspaces or namespaces), each of which can be associated with a different credential for a different cloud. Juju thus supports multi-tenancy.

You can also restrict user access to a model and also restrict the commands that any user can perform on a given model.

See more: Manage models

Harden the applications

When you deploy (an) application(s) from a charm or a bundle, choose the charm / bundle carefully:

  • Choose charms / bundles that show up in the Charmhub search – that means they’ve passed formal review – and which have frequent releases – that means they’re actively maintained.

  • Choose charms that don’t require deployment with --trust (i.e., access to the cloud credentials). If not possible, make sure to audit those charms.

  • Choose charms whose charmcraft.yaml > containers > uid and gid are not 0 (do not require root access). If not possible, make sure to audit those charms.

  • Starting with Juju 3.6: Choose charms whose charmcraft.yaml > containers > charm-user field set to non-root. If not possible, make sure to audit those charms.

  • Choose charms that support secrets (see more: Secret).

Also, keep an application’s charm up to date.

See more: Manage charms

(Like all the cloud resources provisioned through Juju,) the cloud resource(s) (machines or containers) that an application is deployed on by default run the latest Ubuntu LTS. This Ubuntu is not CIS- and DISA-STIG-compliant (see more: Ubuntu | The Ubuntu Security Guide). However, it is by default behind a firewall, inside a VPC; just make sure to expose application or application offer endpoints only as needed and employ firewall rules to restrict inbound and outbound traffic to only necessary ports and IP ranges. Additionally, take advantage of constraints and spaces to minimise over-provisioning and restrict access.

See more: Manage applications

Audit and observe

Juju generates agent logs that can help administrators perform auditing for troubleshooting, security maintenance, or compliance.

See more: Logs

You can also easily collect metrics about or generally monitor and observe your deployment by deploying and integrating with the Canonical Observability Stack.

See more: Collect metrics about a controller (the same recipe – integration with the Canonical Observability Stack bundle – can be used to observe applications other than the controller)