Security

Security in mirrord for Teams

This discussion is only relevant for users on the Team and Enterprise pricing plans.

Love using mirrord but need help getting your security team on board? Talk to one of our technical experts!

Get Security Support

You can also visit our Trust Center for an overview of MetalBear's security posture, certifications, and compliance documentation.

I'm a Security Engineer evaluating mirrord for Teams, what do I need to know?

• mirrord for Teams is completely on-prem. The only data sent to our cloud is analytics and license verification (see details below) which can be customized or disabled upon request. The analytics don't contain PII or any sensitive information.
• mirrord does not require root permissions on the user's machine.
• mirrord for Teams uses Kubernetes RBAC, meaning it doesn't add a new attack vector to your cluster.
• Communication between the mirrord client and the mirrord Operator takes place over your existing Kubernetes API. If you’ve configured your cluster to encrypt this communication (as is commonly done), then mirrord for Teams’ client-server communication is encrypted as well.
• mirrord for Teams defines a new CRD that can be used to limit access and use of mirrord, with plans of more fine-grained permissions in the future.
• The operator requires permissions to create a pod with the following capabilities in its Kubernetes namespace:

  • CAP_NET_ADMIN - for modifying routing tables
  • CAP_SYS_PTRACE - for reading the target pod's environment variables
  • CAP_SYS_ADMIN - for joining the target pod's network namespace
• The operator requires exclusions from the following gatekeeper policies:

  • runAsNonRoot - to access target pod's filesystem
  • HostPath volume/Sharing the host namespace - to access target pod's file system and networking
• mirrord doesn't copy remote files or secrets to the local filesystem. The local app only gets access to remote files and secrets in memory, and so they'll only be written to the local filesystem if done by the local app, or if mirrord was explicitly configured to log to files with a log level of debug/trace.
• Missing anything? Feel free to ask us on Slack or [e-mail]

What data does the mirrord Operator send to MetalBear cloud?

mirrord for Teams is completely on-prem. The Operator communicates with MetalBear servers over an encrypted TLS connection only for license verification and anonymous usage metrics. The fields shared are:

1. User ID (randomly generated hash, stored on user machine)
2. Duration of session
3. Organization name
4. mirrord License Hash (of organization)
5. instance_id (generated on runtime per Operator pod)
6. subscription_id (generated uuid)
7. organization_id (generated uuid)
8. cluster_id (the UID of the cluster's default namespace, used as a stable, anonymous per-cluster identifier)
9. cluster_name (optional; only sent if you set the operator.clusterName Helm value to give the cluster a recognizable label)
10. kubernetes_version (the version of the Kubernetes cluster the Operator is running in)

In the Enterprise offering, this communication can be disabled entirely.

Are you SOC2/ISO27001 compliant?

Yes, MetalBear is SOC2 Type II and ISO27001 certified.

How do I configure Role Based Access Control for mirrord for Teams?

mirrord for Teams works on top of Kubernetes' built-in RBAC with the following resources, mirrordoperators, mirrordoperators/certificate, targets, and targets/port-locks under the operator.metalbear.co apiGroup. The first two resources are required at a cluster level, and the last two can be allowed at a namespace level.

You can limit a user's ability to use mirrord on specific targets by limiting their access to the target resource. The specific verbs for rules to our resources can be copied from the examples below.

For your convenience, mirrord for Teams includes built-in ClusterRoles that control access to the Operator API:

• mirrord-operator-user for interactive users running mirrord locally.
• mirrord-operator-ci for machine sessions in CI runners, such as mirrord ci and mirrord preview.

Both roles grant access to the same Operator API resources by default, but keeping CI access in a separate role lets you bind and label machine identities independently from human users. To grant access to the Operator API, you can create a ClusterRoleBinding like this:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: mirrord-operator-rolebinding
subjects:
- kind: User
  name: jim
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: mirrord-operator-user
  apiGroup: rbac.authorization.k8s.io

For CI runners, bind the runner's ServiceAccount, Kubernetes group, or other authenticated identity to mirrord-operator-ci instead of mirrord-operator-user.

In addition, the Operator impersonates any user that calls its API, and thus only operates on pods or deployments for which the user has get permissions.

To see the latest definition, we recommend checking our Helm chart.

How do I limit user access to a specific namespace?

Create a ClusterRoleBinding between the user and the mirrord-operator-user-basic role, then create a namespaced role (easiest via Helm chart by specifying roleNamespaces) and bind create RoleBinding in the namespace.

How do I limit user access to a specific target?

If the user doesn't have get access to the targets, then they won't be able to target them with mirrord. However, if you want to allow get access to targets but disallow using mirrord on them, we recommend creating a new role based on the mirrord-operator-user namespaced role above, and adding a resourceNames field to the targets resource. This will limit the user to only using the Operator on the specified targets. For example:

- apiGroups:
  - operator.metalbear.co
  resources:
  - targets
  resourceNames:
  - "deployment.my-deployment"
  - "pod.my-pod"
  - "rollout.my-argo-rollout"
  verbs:
  - proxy

How can I prevent users in my team from stealing or mirroring traffic from a target?

You can define policies that prevent stealing (or only prevent stealing without setting a filter) and/or mirroring for selected targets. Let us know if there are more features you would like to be able to limit using policies.

How can I prevent users from using mirrord without going through the Operator?

When the mirrord CLI starts, it checks if an Operator is installed in the cluster and uses it if it's available. However, if the user lacks access to the Operator or if the Operator doesn't exist, mirrord attempts to create an agent directly.

To prevent clients from attempting to create an agent without the Operator, you can add the following key to the mirrord configuration file:

{
  "operator": true
}

To prevent mirrord clients from directly creating agents at the cluster level, we recommend disallowing the creation of pods with extra capabilities by using Pod Admission Policies. Apply a baseline or stricter policy to all namespaces while excluding the mirrord namespace.

Note: before adding a new Pod Admission Policy, you should make sure it doesn't limit any functionality required by your existing workloads.

By default the in-cluster traffic between the operator and its agents isn't encrypted nor authenticated. To ensure encryption and authentication you can enable TLS protocol for the operator–agent connections. You can do this in the operator Helm chart by setting agent.tls to true or manually by setting OPERATOR_AGENT_CONNECTION_TLS=true in the operator container environment. TLS connections are supported from agent version 3.97.0.

Security hardening with the mirrord operator

Here is a quick checklist you may wish to follow in order to improve the security posture of your cluster when using the operator:

Enabling TLS

TLS can be enabled between the operator and mirrord agents to encrypt the traffic they send to each other. From the section above:

By default the in-cluster traffic between the operator and its agents isn’t encrypted nor authenticated. To ensure encryption and authentication you can enable TLS protocol for the operator–agent connections. You can do this in the operator Helm chart by setting agent.tls to true or manually by setting OPERATOR_AGENT_CONNECTION_TLS=true in the operator container environment. TLS connections are supported from agent version 3.97.0.

Reducing access to the mirrord namespace

Users have no need to access to the namespace where mirrord resources are created. By default, this is the mirrord namespace.

Using a certificate for mirrord APIService

By using either your own certificate or one provided by a certificate manager, you can secure access to mirrord's APIService - you will need to set insecureSkipTLSVerify to false in the mirrord-operator Helm chart.

NB: If you are using a certificate manager, make sure you set up reminders for certificate renewal.

Set up network policies for communication

Access to the operator can be further restricted by setting up network policies in the cluster to limit the operator to communicate only with mirrord agents (this is not possible if running agents in ephemeral mode).