---
title: Other Topics
sidebar_label: Other Topics
---

### Advanced Isolation

Besides this basic workload isolation, you could also dive into more advanced isolation methods, such as isolating the workloads on separate nodes or through another container runtime. Using different nodes for your vCluster workloads can be accomplished through the [--node-selector flag](../architecture/nodes.mdx) on vCluster syncer.

You should also be aware that pods created in the vCluster will set their [tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/), which will affect scheduling decisions. To prevent the pods from being scheduled to the undesirable nodes you can use the [--node-selector flag](../architecture/nodes.mdx) or admission controller as mentioned above.

### Workload & Network Isolation within the vCluster

The above mentioned methods also work for isolating workloads inside the vCluster itself, as you can just deploy resource quotas, limit ranges, admission controllers and network policies in there. To allow network policies to function correctly, you'll need to [enable this in vCluster](../networking/networking.mdx) itself though.

### Secret based Service Account tokens

By default vCluster will create Service Account Tokens for each pod and inject them as an annotation in the respective pods
metadata. This can be a security risk in certain scenarios. To mitigate this there's a flag `--service-account-token-secrets` in vCluster
which creates separate secrets for each pods Service Account Token and mounts it accordingly using projected volumes. This option
is not enabled by default but can be enabled on demand. To enable this one can use the `extraArgs` options of the vCluster chart as follows

```
syncer:
  extraArgs:
    - --service-account-token-secrets=true
```
