Skip to main content

We've Moved!

Product Documentation has moved to docs.hitachivantara.com
Hitachi Vantara Knowledge

Security management

This page describes important security consideration for the Content Software for File cluster management.

The Content Software for File system is a secured environment. It deploys a combination of security controls to ensure secured communication and secured user data.

The security controls include the following:

  • HTTPS access: To access the Weka GUI, you connect only to one of the system servers using HTTPS through port 14000.
  • Authentication tokens: The authentication tokens are used for accessing the Weka system API and to allow the mounting of secure filesystems.
  • KMS: When creating an encrypted filesystem, a KMS must be used to properly secure the encryption keys. The KMS encrypts and decrypts filesystem keys.
  • TLS certificates: By default, the system deploys a self-signed certificate to access the GUI, CLI, and API through HTTPS. You can deploy your certificate by providing an unencrypted private key and certificate PEM files.
  • CA certificates: The system uses well-known CA certificates to establish trust with external services. For example, when using a KMS.
  • Account lockout: To prevent brute force attacks, if several login attempts fail (default: 5), the user account is locked for several minutes (default: 2 minutes).
  • Login banner: The login banner provides a security statement or a legal message displayed on the sign-in page.
  • GUI session automatic termination: The user is signed out after 30 minutes of inactivity.

Obtaining authentication tokens

The authentication tokens include two types: an access token and a refresh token.

  • Access token: The access token is a short-live token (five minutes) used for accessing the Weka system API and to allow the mounting of secure filesystems.
  • Refresh token: The refresh token is a long-live token (one year) used for obtaining an additional access token.

Procedure

  1. Do one of the following:

    • To obtain the refresh token and access token, through the CLI, log in to the system using the command: weka user login. The system creates an authentication token file and saves it in: ~/.weka/auth-token.json. The token file contains both the access token and refresh token.GUID-EF881D8F-FDE9-48A7-AE67-3AEEBE8564FF-low.png
    • To obtain the refresh token and access token, through the REST API, use the POST /login. The API returns the token in the response body.GUID-523992B8-0BC3-4924-8ED2-F5358964BEBB-low.png

KMS management using the CLI

Describes the management of the Key Management System (KMS) within the Content Software for File system using the CLI.

Adding or updating a KMS using the CLI

Commandweka security kms set

Use the following command line to add or update the Vault KMS configuration in the Content Software for File system:

weka security kms set <type> <address> <key-identifier> [--token token] [--client-cert client-cert] [--client-key client-key] [--ca-cert ca-cert]
Parameters
NameTypeValueLimitationsMandatoryDefault
typeStringType of the KMSEither vault or kmipYes
addressStringKMS server addressURL for Vault, hostname:port for KMIPYes
key-identifierStringKey to be used for encryptionas-aservice in the KMSKey name (for Vault) or a key UID (for KMIP)Yes
tokenStringAPI token to access Vault KMSMust have:

Read permissions to transit/keys/<master-key-name>

write permissions to transit/encrypt/<master-keyname> and

transit/decrypt/<masterkeyname> permissions to /transit/rewrap and auth/token/lookup

Must be supplied for Vault and must not be supplied for kmip
client-certStringPath to the client certificate PEM fileMust permit encrypt and decrypt permissionsMust be supplied for kmip and must not be supplied for Vault
client-keyStringPath to the client key PEM fileMust be supplied for kmip and must not be supplied for vault
ca-certStringPath to the CA certificate PEM fileOptional for kmip and must not be supplied for vault
NoteFor the add or update command to succeed, the KMS should be preconfigured and available with the key and a valid token.
For example: Setting the Content Software for File system with a Vault KMS:
weka security kms set vault https://vault-dns:8200 weka-key --token s.nRucA9Gtb3yNVmLUK221234

Setting the Content Software for File system with a KMIP complaint KMS (for example, SmartKey):

weka security kms set kmip amer.smartkey.io:5696 b2f81234-c0f6-4d63-b5b3-84a82e231234 --client-cert smartkey_cert.pem --client-key smartkey_key.pem

Viewing the KMS using the CLI

Command

weka security kms

Use this command to show the details of the configured KMS.

Removing the KMS using the CLI

Command

weka security kms unset

Use this command to remove the KMS from the Content Software for File system. It is only possible to remove a KMS configuration if no encrypted filesystems exist.

NoteTo force remove a KMS even if encrypted filesystems exist, use the --allow-downgrade attribute. In such cases, the encrypted filesystem keys are re-encrypted with local encryption and may be compromised.

Re-wrapping filesystem keys using the CLI

Commandweka security kms rewrap

If the KMS key is compromised or requires rotation, the KMS admin can rotate the key in the KMS. In such cases, this command is used to re-encrypt the encrypted filesystem keys with the new KMS master key.

weka security kms rewrap [--new-key-uid new-key-uid]
Parameters
NameTypeValueLimitationsMandatoryDefault
new-key-uidStringUnique identifier for the new key to be used to wrap filesystem keysMust be supplied for kmip and must not be supplied for Vault
NoteExisting filesystem keys that are part of the Snap-To-Object feature will not be automatically re-encrypted with the new KMS key.
NoteUnlike in Vault KMS, re-wrapping a KMIP-based KMS requires generating a new key in the KMS, rather than rotating the same key. Hence, the old key should be preserved in the KMS in order to be able to decrypt old Snap2Obj snapshots.

Setting-up Vault configuration

The setting up of the Vault configuration is described.

Enabling transit secret engine in vault

The Weka system uses encryption-as-a-service capabilities of the KMS to encrypt/decrypt the filesystem keys. This requires the configuration of Vault with the transit secret engine.

$ vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/

For more information, see Vault transit secret-engine documentation.

Setting-up the master key for the Content Software for File system

Once the transit secret engine is set up, a master key for use with the Content Software for File system must be created.

$ vault write -f transit/keys/weka-key
Success! Data written to: transit/keys/weka-key
NoteIt is possible to either create a different key for each Content Software for File cluster or to share the key between different clusters.

For more information, refer to Vault transit secret-engine documentation.

Creating a policy for master key permissions

Create a wekaio_policy.hcl file with the following content:

path "transit/+/weka-key" {
  capabilities = ["read", "create", "update"]
}
path "transit/keys/weka-key" {
  capabilities = ["read"]}

This limits the capabilities so there is no permission to destroy the key, using this policy. This protection is important when creating an API token.

Create the policy using the following command:

$ vault policy write weka weka_policy.hcl

Obtaining an API token from Vault

Authentication from the Content Software for File system to Vault relies on an API token. Since the Content Software for File system must always be able to communicate with the KMS, a periodic service token must be used. To obtain the token, follow the next steps:

  • Verify that the token authentication method in Vault is enabled. This can be performed using the following command:
    $ vault auth list
    
    Path         Type        Description
    ----         ----        -----------
    token/       token       token based credentials
  • To enable the token authentication method use the following command:
    $ vault auth enable token
  • Log into the KMS system using any of the identity methods supported by Vault. The identity should have permission to use the previously-set master key.
  • Create a token role for the identity using the following command:
    $ vault write auth/token/roles/weka allowed_policies="weka" period="768h"
    Notehe period is the time set for a renewal request. If no renewal is requested during this time period, the token will be revoked and a new token must be retrieved from Vault and set in the Weka system.
  • Generate a token for the logged-in identity using the following command:
    $ vault token create -role=weka
    
    Key                  Value
    ---                  -----
    token                s.nRucA9Gtb3yNVmLUK221234
    token_accessor       4Nm9BvIVS4HWCgLATc3r1234
    token_duration       768h
    token_renewable      true
    token_policies       ["default"]
    identity_policies    []
    policies             ["default"]

For more information on obtaining an API token, see Vault Tokens documentation.

NoteThe Content Software for File system does not automatically renew the API token lease. It can be renewed using the Vault CLI/API. It is also possible to define a higher maximum token value (max_lease_ttl) by changing the Vault Configuration file.

Obtaining a certificate for a KMIP-based KMS

The method for obtaining a client certificate and key and set it using the KMS is different for each KMS. The certificate itself will be generated using OpenSSL, with some UID obtained from the KMS, for example:

openssl req -x509 -newkey rsa:4096 -keyout client-key.pem -out client-cert.pem -days 365 -nodes -subj '/CN=f283c99b-f173-4371-babc-572961161234'

Consult the specific KMS documentation to create a certificate and link it to the Content Software for File cluster in the KMS with sufficient privileges (encrypt/decrypt).

See SmartKey KMS to create a client certificate and key, and to assign a certificate for Content Software for File within SmartKey.

Getting started with REST API

The Content Software for File system supports a RESTful API. This is useful when automating the interaction with the Content Software for File system and when integrating it into your workflows or monitoring systems.

The API is accessible at port 14000, via the /api/v2 URL, you can explore it via /api/v2/docs when accessing from the cluster (e.g. https://weka01:14000/api/v2/docs).

Our static API documentation can be accessed from api.docs.weka.io (the version can be selected from the drop-down list). The .json file can also be used to create your client code, using an OpenAPI client generator.

Obtain an access token

You must provide an access token to use the Content Software for File REST API.

To obtain access/refresh tokens via the CLI, refer to Obtaining an Authentication Token section (there you can also generate an access token with a longer expiry time). To obtain access/refresh tokens via the API, you can call the login API, providing it a username and password .

If you already obtained a refresh token, you can use the login/refresh API to refresh the access token.

{% tabs %} {% tab title="Login" %} {% code title="Python example calling the login API" %}

import requests

url = "https://weka01:14000/api/v2/login"

payload="{\n    \"username\": \"admin\",\n    \"password\": \"admin\"\n}"
headers = {
  'Content-Type': 'application/json'
}

response = requests.request("POST", url, headers=headers, data=payload)

print(response.text)

{% endcode %} {% endtab %}

{% tab title="Refresh" %} {% code title="Python example calling the login refresh API" %}

import requests

url = "https://weka01:14000/api/v2/login/refresh"

payload="{\n    \"refresh_token\": \"REPLACE-WITH-REFRESH-TOKEN\"\n}"
headers = {
  'Content-Type': 'application/json'
}

response = requests.request("POST", url, headers=headers, data=payload)

print(response.text)

{% endcode %} {% endtab %} {% endtabs %}

In response, you will get an access token (valid for 5 minutes), that can be used in the other APIs that require token authentication, along with the refresh token (valid for 1 year), for getting additional access tokens without using the username/password.

{% code title="Login/Refresh Response" %}

{
  "data": [
    {
      "access_token": "ACCESS-TOKEN",
      "token_type": "Bearer",
      "expires_in": 300,
      "refresh_token": "REFRESH-TOKEN"
    }
  ]
}

{% endcode %}

Call the REST API

Now, that you have obtained an access token, you can call Content Software for File REST API commands with it. For example, you can query the cluster status:

{% code title="Python example calling cluster status API" %}

import requests

url = "https://weka01:14000/api/v2/cluster"

payload={}
headers = {
  'Authorization': 'Bearer REPLACE-WITH-ACCESS-TOKEN'
}

response = requests.request("GET", url, headers=headers, data=payload)

print(response.text)

{% endcode %}

Managing the TLS certificate using the CLI

How to deploy and replace the TLS certificate using the CLI.

Setting the TLS certificate using the CLI

You can set your TLS certificates using the CLI command:

weka security tls set

The command receives an unencrypted private key.

This command is similar to the OpenSSL command that Content Software for File uses to generate the self-signed certificate: .
openssl req -x509 -newkey rsa:1024 -keyout key.pem -out cert.pem -days <days> -nodes

Replacing the TLS certificate using the CLI

To replace the TLS certificate with a new one, use the CLI command:

weka security tls set

Once you issue a TLS certificate, it is used for connecting to the cluster (for the time it is issued), while the revocation is handled by the CA and propagating its revocation lists into the various clients.

Unsetting the TLS certificate

You can unset your TLS certificates using the CLI command:

weka security tls unset

Downloading the TLS certificate using the CLI

To download the TLS certificate, use the CLI command:

weka security tls download

Viewing the TLS certificate status using the CLI

To view the cluster TLS status and certificate, use the CLI command:

weka security tls status

Managing the CA certificate using the CLI

Content Software for File uses well-known CAs to establish trust with external services. For example, when using a KMS.

Use the CLI command:

weka security ca-cert set

Managing the account lockout threshold policy using CLI

To control the default values, use the following CLI commands:

weka security lockout-config set|show|reset
Commands options:

set: Sets the number of failed attempts until the account is locked (--failed-attempts) and the lockout duration (--lockout-duration).

reset: Resets the number of failed attempts until the account is locked and the lockout duration to their default values.

show: Shows the number of failed attempts until the account is locked and the lockout duration.

Managing the login banner using the CLI

To manage the login banner, use the following CLI command:

weka security login-banner set|show|reset|enable|disable
Command options:

set: Sets the login banner text.

show: Shows the login banner text.

reset: Clears the login banner text.

enable: Displays the login banner when accessing the cluster.

disable: Prevents displaying the login banner when accessing the cluster.

 

  • Was this article helpful?