Storage
Store objects as blobs within containers on Azure Blob storage.
Overview
Storage in MedStack Control is powered by Azure Blob storage.
Azure Blob storage is an object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data. Unstructured data is data that doesn't adhere to a particular data model or definition, such as text or binary data.
There are two main components when interacting with object storage in MedStack Control.
- Generating shared access signature (SAS) tokens to containers and blobs.
- Using SAS tokens in calls to the Azure Storage REST API or Azure CLI.
Get started
Before you get started
Take a moment to familiarize yourself with the introduction to Azure Blob storage as you will be interfacing with the Azure Storage REST API or Azure CLI to access your object store.
The first step in storing large amounts of data in an object storage on MedStack Control is to create a storage account in the cluster. There is a limit of one (1) storage account per cluster.
Creating the storage account displays the storage account name and the key selected which is used for generating SAS tokens.
| Field | Description |
|---|---|
| Name | Randomly generated storage account name |
| Key for tokens | Indicates which key is currently being used to generate access tokens |
Security
The default configuration of the storage account makes it only accessible to resources within the cluster. This is congruent with how cluster networking is configured on MedStack Control.
Global storage account or token-specific rules may be configured to permit select IP addresses with access to containers and blob within the storage account. This is helpful when connecting an external endpoint to the object store, like a development machine.
Storage Account Keys
The storage account keys are not accessible
As a measure to protect the integrity of backups and data in the object store, the storage keys are not provided to users.
Azure storage comes with two (2) auto-generated 512-bit storage account access keys that are used to generate SAS tokens. In MedStack Control, these keys are labeled as Primary and Secondary.
MedStack never stores the content of the keys, but it stores the name of the key used to generate SAS Tokens.
Backup and Restore
Azure Storage backup and restore process is done at the container level, instead of the blob level. This means that all the blobs within the container are backed up and restored together as a unit.
The process involves creating transactional backups, where each change is recorded as a transaction for point-in-time in-place restore. The backups are retained for up to 35 days.
To restore a backup, a support ticket must be created with the Storage Account ID and desired restore point. Our support team will then perform the restore and update you once it is completed.
It's important to note that restoring a container will overwrite the entire container, including all the blobs within it. This means that any changes made to the blobs after the specified restore point will be lost.
It's also important to note that the storage backups are deleted when the cluster is deleted.
Manage
Clicking the "Manage" button navigates you to a section where you can perform more actions on your storage.
On the top of this page, you will find two (2) tabs:
Containers
A container organizes a set of blobs, similar to a directory in a file system. A storage account can include an unlimited number of containers, and a container can store an unlimited number of blobs.
Containers, in this context, should not be confused with Docker containers. Storage containers can be seen as folders; it is just a logical entity with the goal of organizing your data.
In this section you can Create containers or Generate tokens for containers or the blobs within a container.
Switch or regenerate keys
Inside the Actions dropdown button, you will find options to manage the key selected for generating SAS tokens. Those options are:
- Switch key (from primary to secondary, or vice-versa)
- Regenerate key (for primary or secondary)
Switch storage account key
Use this action to change the key that MedStack Control use to generate SAS tokens.
Regenerate key for storage account
Use this action to regularly roll all your storage keys. We'll see later what this exactly entails in this example.
SAS Tokens
You can generate SAS (Shared Access Signature) tokens for containers or blobs. MedStack Control will provide you with a list of containers only. There is currently no way to explore the content of a container in MedStack Control.
Browse your object store with Azure Storage Explorer
You can use the Azure Storage Explorer to upload, download, and manage Azure blobs on your local machine in a few simple steps.
- Download the Azure Storage Explorer.
- Create a new rule to allow the IP address of your local machine.
- Create a container.
- [Generate] an SAS token for the container.
- Connect to the storage account via the Storage Explorer selecting the option to "use a shared access signature (SAS) URI."
Generate
You can generate SAS tokens with scopes for entire containers or for specific blob. This can be done by clicking the Generate token button for a container in the container list.
You must fill out the token form. Optionally, you can allow an IP address range, permitting select IP addresses to use the SAS token.
You can learn more about SAS tokens on the official Azure documentation
Once a token is generated, you will see two (2) links at the bottom of the form. The content of these links is not stored anywhere, so once you navigate away from this page, the links are lost. However, if you forget to capture the token and URL, you can always generate another token with the same parameters.
The token can now be used in your application according to its permissions.
Make sure you capture the SAS token and URL
The content of the SAS token and SAS URL fields is not stored anywhere, so once you navigate away from this page, the links are lost.
Allowed IPs
If you need to access your blobs or containers outside of MedStack, you can create rules to allow specific IPs to access the storage. Make sure to delete rules once they are no longer needed. In doing so, this will help keep your security tight.
Allowed IP address vs Allowed IP range
Allowed IP addresses operate at the storage level: if you don't allow an IP address outside of MedStack Control, you won't be able to access the storage at all.
As a second layer of security, optionally, you can use the Allowed IP range offered by the SAS Token page, so even if you have multiple IP addresses allowed to access the storage, only the ones specified by the token option will be able to access the specific resource for which the token was generated.
Example: Regenerating your access keys
The main reason why the storage comes with two (2) access keys is to make the process of regenerating the keys easier and smoother.
If you suspect your access key becomes compromised, or more simply you want to update your keys regularly, this is a standard protocol you may follow:
- Switch the key used for tokens.
- Generate new tokens and replace them in your applications where needed.
- Regenerate the access key switched in step 1.
For example, if you are currently using the secondary key to create access tokens, you would:
- Switch to use the primary key.
- Generate new tokens and implement them where needed.
- Regenerate the secondary key.
Always replace all the tokens before regenerating a storage key
Regenerating a storage key will immediately invalidate all the tokens singed with that key.
This could potentially create outages or glitches in your applications if you don't provide new tokens first.
Updated about 1 year ago