We’re officially more than halfway 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!
Kubernetes Security Posture Review (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, redundant, and protected. Kubernetes and cloud infrastructure help 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 open-source 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 your AWS accounts in CloudCasa, the same as you would 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.
More information on CloudCasa security features is coming soon in the form of online documentation and blog posts.
Granular Kubernetes Restores based on Resource Type
When doing a restore of a Kubernetes cluster, you can now select exactly which types of resources (secrets, cronjobs etc.) you would like to restore. In the restore wizard, you can select from discovered resource types or enter custom resources manually. The default is to restore all resource types.
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 them to an alternate namespace.
Enhanced Cross-Cluster Restores
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 an EKS cluster on restore, the system now allows you to customize the IAM role, subnet group, security group etc. to use in a new account or region. This minimizes the need for user intervention and allows a “bare metal recovery” like functionality.
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. 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.
This feature 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. The Starter plan includes up to 5 in an organization, and Pro and Pro+ plans include up to 64.
Updating agents can be a drag, and not having the latest agent can prevent you from using the latest CloudCasa features. So we’rehappy 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 when no backups or restores are running. 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.
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.
We’ve made some significant changes to the CloudCasa UI in order to 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 username.
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 updated instructions.
CloudFormation Stack Update
Our AWS CloudFormation stack was updated to add the permissions necessary for security scanning. You can re-launch the stack for existing AWS accounts under the Configuration/Cloud Accounts tab to apply the update.