Skip to content

Latest commit

 

History

History
240 lines (188 loc) · 8.15 KB

charm-easyrsa.md

File metadata and controls

240 lines (188 loc) · 8.15 KB
Raw
wrapper_template markdown_includes context keywords tags sidebar permalink layout toc charm_revision charm_name bundle_release
templates/docs/markdown.html
nav
kubernetes/docs/shared/_side-navigation.md
title description
Easyrsa charm
Delivers EasyRSA to create a Certificate Authority (CA).
component, charms, versions, release
reference
k8smain-sidebar
1.19/charm-easyrsa.html
base
ubuntu-com
false
339
easyrsa
1.19

This charm delivers the EasyRSA application to act as a Certificate Authority (CA) and create certificates for related charms.

Deployment

To deploy EasyRSA:

juju deploy cs:~containers/easyrsa

Using the EasyRSA charm

The EasyRSA charm will become a Certificate Authority (CA) and generate a CA certificate. Other charms need only to relate to EasyRSA with a requires using the tls-certificates interface.

To get a server certificate from EasyRSA, a charm must include the interface:tls-certificates interface in its layer.yaml file. The charm must also require the tls interface, in its metadata.yaml. The relation name may be named what ever you wish. Assume the relation is named "certificates" for these examples.

CA

The interface will generate a CA certificate immediately. If another charm requires a CA certificate the code must react to the flag certificates.ca.available. The relationship object has a method named get_ca which returns the CA certificate.

@when('certificates.ca.available')
def store_ca(tls):
    '''Read the certificate authority from the relation object and install it
    on this system.'''
    # Get the CA from the relationship object.
    ca_cert = tls.get_ca()
    write_file('/usr/local/share/ca-certificates/easyrsa.crt', ca_cert)

Client certificate and key

The EasyRSA charm generates a client certificate after the CA certificate is created. If another charm needs the CA the code must react to the flag certificates.client.cert.available. The relationship object has a method that returns the client cert and client key called get_client_cert.

@when('certificates.client.cert.available')
def store_client(tls):
    '''Read the client certificate from the relation object and install it on
    this system.'''
    client_cert, client_key = tls.get_client_cert()
    write_file('/home/ubuntu/client.crt', client_cert)
    write_file('/home/ubuntu/client.key', client_key)

Request a server certificate

The interface will set certificates.available flag on a relation. The reactive code should send three values on the relation to request a certificate. Call the request_server_cert method on the relationship object. The three values are: Common Name (CN), a list of Subject Alt Names (SANs), and the file name of the certificate (the unit name with the '/' replaced with an underscore). For example a client charm would send:

@when('certificates.available')
def send_data(tls):
    # Use the public ip of this unit as the Common Name for the certificate.
    common_name = hookenv.unit_public_ip()
    # Get a list of Subject Alt Names for the certificate.
    sans = []
    sans.append(hookenv.unit_public_ip())
    sans.append(hookenv.unit_private_ip())
    sans.append(socket.gethostname())
    # Create a path safe name by removing path characters from the unit name.
    certificate_name = hookenv.local_unit().replace('/', '_')
    # Send the information on the relation object.
    tls.request_server_cert(common_name, sans, certificate_name)

Server certificate and key

The Easy-RSA charm generates the server certificate and key after the request have been made. If another charm needs the server certificate the code must react to the flag {relation_name}.server.cert.available. The relationship object has a method that returns the server cert and server key called get_server_cert.

@when('certificates.server.cert.available')
def store_server(tls):
    '''Read the server certificate from the relation object and install it on
    this system.'''
    server_cert, server_key = tls.get_server_cert()
    write_file('/home/ubuntu/server.cert', server_cert)
    write_file('/home/ubuntu/server.key', server_key)

Backup/Restore the PKI

This charm includes actions which support creating and managing snapshots of the Easy-RSA PKI. Their usage is explained in the following sections:

Create backups

Use the charm's backup action to capture current snapshot of the Easy-RSA PKI. This will generate a file in the directory /home/ubuntu/easyrsa_backup on the relevant unit. The backup file follows the naming convention: easyrsa-YYYY-MM-DD_HH-MM-SS.tar.gz.

For example:

juju run-action --wait easyrsa/0 backup

For convenience, the output of the backup action will output the exact juju scp command to download the created file to your local machine.

List backups

To list all the available backup files stored on the unit, run the following:

juju run-action --wait easyrsa/0 list-backups

This will output a list of filenames. These filenames are relative to the unit's /home/ubuntu/easyrsa_backup/ directory.

The names can be used either directly as a parameters for the restore and delete-backup actions or as part of a juju scp command to download the backup files. For example, to download a backup named easyrsa-2020-12-10_16-37-54.tar.gz, the corresponding juju scp command would be:

juju scp easyrsa/0:/home/ubuntu/easyrsa_backup/easyrsa-2020-12-10_16-37-54.tar.gz .

Delete backups

To delete a backup file stored on the unit, simply run action delete-backup with parameter name=<backup_name>. List of all available backups can be obtained by running action list-backups. To remove all the backups from the unit, you can specify parameter all=true.

Removing a single backup:

juju run-action --wait easyrsa/0 delete-backup name=easyrsa-2020-12-10_16-37-54.tar.gz

Removing all backups:

juju run-action --wait easyrsa/0 delete-backup all=true

Restore backups

To restore a backup, run the restore action. This action takes one parameter, name, which specifies the backup file to be restored. This file must exist on the easyrsa unit for the action to succeed. A list of the available backups can be obtained by running the list-backups action.

For example:

juju run-action --wait easyrsa/0 restore name=easyrsa-2020-06-10_16-37-54.tar.gz

In the case where the backup file is available locally, it can be copied to the relevant unit before running the restore action by using the juju scp command. For example:

juju scp easyrsa-2020-12-10_16-37-54.tar.gz easyrsa/0:/home/ubuntu/easyrsa_backup/

In the case where units have been added to the Juju model since the backup was created, Easy-RSA will issue new certificates to these units.

Warning: There is a known issue thatthe `kubernetes-master` units need to be restarted after the certificate change. These units may settle in the active/idle state but all new pods will hang in the pending state. .

Note:

The Easy-RSA charm notifies all the related units that the CA and issued certificates have changed. It's up to the implementation of each related charm to react to this change properly. It may take up to several minutes for model to settle back into the active/idle state.

Actions

This section covers Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis. To display action descriptions you can run juju actions easyrsa, inspect the charm's actions.yaml file or consult the table below: