Security - mirrord for Teams

Available for:

Team Enterprise

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 which can be customized or disabled upon request. The analytics don’t contain PII or any sensitive information.
  • mirrord for Teams uses Kubernetes RBAC, meaning it doesn’t add a new attack vector to your cluster.
  • The Kubernetes operator installed in the cluster as part of mirrord for Teams is licensed as Source Available (but not yet public) and we’ll be happy to share the code if needed for review.
  • 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 job 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
  • 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 Discord or [email protected]

Are you SOC2/GDPR compliant? #

mirrord for Teams is completely on-prem and doesn’t process your customer data, so SOC2 and GDPR don’t apply to it.

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 a built-in ClusterRole called mirrord-operator-user, which controls access to the Operator API. 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

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.

Edit this page on GitHub