Feature Update February 2022

We’re officially more than half-way through winter here in the northern hemisphere, and although that famous Pennsylvania groundhog Punxsutawney Phil has just predicted six more weeks of cold and snow, we have some good news that we think helps make up for it. We’re announcing a major new release of CloudCasa features!

Organization support

It’s been a long time coming, but we are happy to announce that organization support is finally here! This allows multiple user logins to share access to an account and the resources within it.

By default, everyone is an administrator of their own organization, which is named “default”. You can set your organization name under Configuration/General, and invite additional users to join it under Configuration/Users. Invited users will receive an email notification with instructions on the actions they should take, depending on whether or not they have existing CloudCasa accounts. Upon login, they can choose to accept, decline, or temporarily ignore the invitation.

A user can belong to multiple organizations, but can only have one at a time active in the UI. To change your active organization, open the user menu in the top right corner and select “Switch Organization”.

Basic role-based access control (RBAC) support is included. Users can have one of the roles User, Admin, or Billing Admin. The User role has access to most CloudCasa functions, with the exception of the Users, API Keys, Billing & Payments, and Service Plans configuration pages. These require the Admin or Billing Admin role. Only accounts that are signed up for paid services have a Billing Admin. The Billing Admin serves as the billing contact, and has access to the billing-related Configuration pages. By default, the Admin who signs up for paid services will become the Billing Admin. Support for more flexible and fine-grained RBAC will follow shortly.

An organization with free service can have up to three users. An organization with any with premium service plan can have an unlimited number.

Kubernetes security posture management (Beta)

Keeping your data and applications safe is about more than just backups. Achieving cyber resilience requires providing multiple layers of resiliency for your critical IT infrastructure. It should be secure, it should be redundant, and it should be protected. Kubernetes and cloud infrastructure help with the redundancy. CloudCasa now helps you with both of the other two!

CloudCasa now allows users to perform a security posture review on their Kubernetes clusters, and on their related AWS cloud infrastructure. We provide this capability using a curated collection of best-of-breed opensource security tools. The results are provided in the CloudCasa UI under the new Security tab, where they can be searched, filtered, sorted, and flagged. Results can also be exported in CSV format.

Kubernetes security scans are performed by the CloudCasa Kubernetes agent. AWS cloud security scans are executed by the CloudCasa service provider infrastructure using cross-account roles. For this to work, you need to configure you AWS accounts in CloudCasa, the same as you would to enable other AWS features like RDS snapshots, EKS cluster auto-discovery, and EKS cluster creation on restore.

Free users can perform up to three Kubernetes scans per cluster per month, and one cloud infrastructure scan per month. They can store the results for 30 days. Premium service users can perform many more scans, can schedule scans to run automatically, and can store the results for up to a year plus one day.

More information on CloudCasa security features is coming soon in the form of online documentation, blog posts, and FAQ entries.

Selecting Kubernetes resources for restore by type

When doing a restore of a Kubernetes cluster, you can now select exactly which types of resources you would like to restore. In the restore wizard you can select from discovered resource types or enter them manually. The default is to restore all resource types as before.

Note that the restore will not overwrite existing resources, so if you want to restore specific resources to an existing cluster/namespace we suggest either manually removing existing resources first or restoring to an alternate namespace.

Also note that is you wish to select only pv and pvc resources, you also need to select pod resources for the restore to work properly. In the future this will happen automatically.

Cross-cluster restore improvements

We’ve been working on many enhancements for cross-cluster, cross-account, and cross-cloud restores. Several of these have been introduced in this release.

First, we’ve added support for cross-account Kubernetes restores in AWS. The system will now automatically handle changing volume IDs for PVs.

Second, when creating a EKS cluster on restore, the system now asks for the IAM role to use in a new account. This allows for cluster creation on restore in a different account.

Third, when restoring to an existing cluster other than the original cluster, users can now browse the available storage classes in the destination cluster. This makes remapping storage classes quicker and easier. Note that this information isn’t available when creating a new cluster on restore.

In general, cross-cluster restores should work with no user intervention as long as matching storage classes exist on the target cluster. If they don’t, you should use the option to remap storage classes to those that exist on the target. We generally recommend restoring individual namespaces rather than the full cluster when restoring to an existing cluster. Also, only copy backups should be restored to a different target cluster, not snapshot backups. Finally, CloudCasa supports only dynamically provisioned PVs for automatic cross-cluster restore.

Agent auto-updates

Updating agents can be a drag, and not having the latest agent can prevent you from using the latest CloudCasa features. So we’re happy to announce that the CloudCasa Kubernetes agent has been re-designed so that it can automatically update itself. The agent has essentially been split into two parts, an agent and an agent manager. The agent manager will periodically check for available updates to the agent and install them if required. Manual upgrades will now only be required for changes to the agent manager.

An option to disable automatic agent updates will be available soon, but we recommend that you don’t use it in normal circumstances.

Azure object store support for BYO Storage

When we released the Bring Your Own Storage feature in December, we promised that support for user-supplied Azure blob storage would be coming soon. Now it’s here!

The following info if required to configure Azure blob storage under Configuration/My Storage: region, resource group name, subscription ID, client ID, client secret, and tenant ID.

CloudCasa requires permissions to invoke read, write, and list APIs on the resource group, since we need to create storage account and container under the resource group.

Online help

We’ve worked hard to make CloudCasa as easy to use as possible, and to make the UI self-explanatory. For the most part we think we’ve succeeded. But CloudCasa now has a lot of sophisticated features, and sometimes there is no substitute for documentation. So we are happy to announce that context sensitive help is now available by clicking the Help icon on the top bar.

A limited number of help topics are available initially, but we will be adding additional topics and updating existing topics on a regular basis.

UI Changes

We’ve made some significant changes to the CloudCasa UI in order fit in all of the new features. The most important to be aware of are the following:

The configuration pages from the Configuration and Preferences tabs have all been reorganized under the Configuration tab, with a quick-access menu now provided when you mouse over the tab. User preference settings are still reached from the user menu.

Cloud account configuration has been moved from the Protection tab to the Configuration tab, since cloud accounts are now used for both Protection and Security functions.

All of the new security-related features are grouped under the new Security tab.

A switch organization function has been added to the top of the user menu, and the current organization is displayed in the top right corner under the user name.

Kubernetes agent update

In this release we’ve again made several changes to our Kubernetes agent to add features, improve performance, and fix bugs. You should update any existing CloudCasa agents. The good news is that, because of the new automatic agent update feature, you should need to do this much less often in the future!

Agent and Helm chart updates for partner marketplaces such as Rancher and Digital Ocean, and Operator updates for OpenShift, should be available within the next few weeks. See the FAQ for update instructions.

CloudFormation stack update

Our AWS CloudFormation stack was updated in order to add the permissions necessary for security scanning. You can re-launch the stack under the Protection/Accounts tab to apply the update to existing accounts.

Notes

With some browsers you may need to restart, hit Control-F5, and/or clear the cache to make sure you have the latest version of the CloudCasa web app when first logging in after the update.

As always, we want to hear your feedback on new features! You can contact us via the user forum, using the support chat feature, or by sending email to support@cloudcasa.io.