The KX Managed Application kdb Insights Enterprise Azure Marketplace bundle is secure by design and follows the Azure security baseline for Azure Managed Applications.
You can access the standard Azure security features like:
Activity log events are automatically generated and collected for viewing in the Azure portal. This covers subscription-level events that track operations for each Azure resource, for example, creating a new resource or starting a virtual machine.
Activity log events are retained in Azure for 90 days and then deleted. There's no charge for entries during this time regardless of volume.
See Azure Monitor activity log for further details.
Azure role-based access control (Azure RBAC) is the authorization system you use to manage access to Azure resources.
The below blade allows you to examine the current Role assignments, modify or delete them or create new assignments.
See What is identity and access management (IAM)? for further details.
Application level role-based access control is implemented through Keycloak:
- You can find out more about it in the Authentication topic.
- Its configuration is documented in the Configuration topic.
The Security blade gives you access to the Microsoft Defender for Cloud. It is a Cloud Security Posture Management (CSPM) and Cloud Workload Protection Platform (CWPP) for Azure resources.
To get the full power of Microsoft Defender for Cloud you need to enable it on your Subscription. You can check the Microsoft Defender for Cloud pricing to understand how it is billed.
Azure Policies help to enforce organizational standards and to assess compliance at scale. Through its compliance dashboard, it provides an aggregated view to evaluate the overall state of the environment, with the ability to drill down to the per-resource, per-policy granularity.
The kdb Insights Enterprise Azure Marketplace bundle deploys the following custom policies into the main Resource group of each deployment:
Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types.
ClusterRole/system:aggregate-to-edit should not allow endpoint edit permissions due to CVE-2021-25740, Endpoint & EndpointSlice permissions allow cross-Namespace forwarding, https://github.com/kubernetes/kubernetes/issues/103675. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes.
Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes.
Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes.
Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for Azure Arc enabled Kubernetes.
Upgrade your Kubernetes service cluster to a later Kubernetes version to protect against known vulnerabilities in your current Kubernetes version.
Azure Kubernetes Service's resource logs can help recreate activity trails when investigating security incidents. Enable it to make sure the logs will exist when needed
Protect your Kubernetes clusters and container workloads from potential threats by restricting deployment of container images with vulnerable software components.
Container image vulnerability assessment scans container images running on your Kubernetes clusters for security vulnerabilities and exposes detailed findings for each image. Resolving the vulnerabilities can greatly improve your containers' security posture and protect them from attacks.
For more information, see https://aka.ms/kubepolicydoc.
When a deployment is healthy all of the KX deployed policies should be in a Compliant state:
Some of the policies take a while to become compliant as they rely on data collected from containers.
If Microsoft Defender for Cloud is enabled on your subscription then additional policies will be available. In order to comply with some of these policies you need to enable Microsoft Defender for Containers either by following this procedure or selecting the below checkbox during the deployment:
A few of these policies will take some time to become
Compliant and you may need to take some actions:
Endpoint protection solution should be installed on virtual machine scale sets
Vulnerabilities in security configuration on your virtual machine scale sets should be remediated
System updates on virtual machine scale sets should be installed
Log Analytics agent should be installed on your virtual machine scale sets for Azure Security Center monitoring
Running container images should have vulnerability findings resolved
Azure DDoS Protection Standard should be enabled
Vulnerabilities in container security configurations should be remediated
Some policies may stay in a
Non-compliant state for an extended time:
- Authorized IP ranges should be defined on Kubernetes Services
In order for IMS to manage the AKS cluster on your behalf, they need to connect through the Internet.
- Secure transfer to storage accounts should be enabled
The Storage Account providing ReadWriteMany volumes cannot be forced to use HTTPS only as the NFS protocol does not support it.
- All Internet traffic should be routed via your deployed Azure Firewall
Azure Firewall is not a free service and it needs to be configured according to your needs.
This is the default set of policies monitored by Microsoft Defender for Cloud. It is automatically assigned as part of your onboarding to Microsoft Defender for Cloud. The default assignment contains only audit policies. For more information please visit https://aka.ms/ascpolicies
Alerts help you detect and address issues before users notice them by proactively notifying you when Azure Monitor data indicates there might be a problem with your infrastructure or application.
The kdb Insights Enterprise Azure Marketplace bundle deploys two types of Alert rules to allow early detection of various problems:
An Alert rule combines:
- The resources to be monitored,
- The signal or telemetry from the resource,
- And Conditions.
Please read more on this topic here: Azure Monitor alerts
During normal operating conditions there should be no Alerts present on the Azure Portal:
You can opt-in to receive Alert notifications whenever an Alert is created by a rule. For this you only need to specify a recipient in the Advanced Settings section:
In case of KX Managed Application the Insights Managed Service (IMS@kx.com) is automatically notified about the default Alerts.
The deployment consists of a single Virtual network that has two Subnets:
The kdb Insights Enterprise User Interface (UI) is accessible through a Public IP address that is associated with a DNS name of the format:
This address is publicly accessible so your users can conveniently connect to it over a secure channel from anywhere on the Internet.
There are two more Public IP addresses created by default that are used for the REST API. And every Assembly deployed will create 3 more Public IP addresses each.
The default deployment includes a Network Security Group managed by AKS which is associated with the Network interfaces of the cluster node VMs:
To harden the network and increase your security you can use various Azure services and solutions:
- Configure the above Network Security Group and associate it with the whole Subnet instead.
- Deploy an Azure Bastion into your Vnet.
- Enable Azure DDoS Protection on the Vnet.
- Enable Azure Firewall on the Vnet.
- You can create Service endpoints in the Vnet to have secure and direct connectivity to other Azure services.
- You can set up Virtual network peering
to seamlessly connect it to your other Vnet(s).
- Please note that the default Address space of the deployed Vnet is
10.0.0.0/16and make sure that there is no overlap between the Address spaces of the peered Vnets.
- You can change the Address space during the deployment but it must be a valid CIDR Address space of this format:
- Please note that the default Address space of the deployed Vnet is
You can read more on this topic at the Azure network security overview documentation.
Two Storage accounts are created for the deployment. One to store the diagnostic logs of the cluster and another one to provide NFS service to the cluster:
Public network access to these storage accounts has been disabled during the deployment to protect your data. The application uses private endpoint connections to access them: