github.com/Azure/aad-pod-identity@v1.8.17/website/content/en/docs/Configure/feature_flags.md (about) 1 --- 2 title: "Feature Flags" 3 linkTitle: "Feature Flags" 4 weight: 5 5 description: > 6 Optional configuration feature flags. 7 --- 8 9 ## Enable Scale Features flag 10 11 > Available from 1.5.3 release 12 > This flag is enabled by default starting from v1.8.1 release 13 14 AAD Pod Identity adds labels to `AzureAssignedIdentities` which denote the nodename, podname and podnamespace. 15 When the optional parameter `enableScaleFeatures` is set to `true`, the NMI watches for `AzureAssignedIdentities` will do a label based filtering on 16 the nodename label. This approach is taken because currently Kubernetes does not support field selectors in CRD watches. This reduces the load which 17 NMIs add on API server. When this flag is enabled, NMI will no longer work for `AzureAssignedIdentities` which were created before 1.5.3-rc5, since 18 they don't have the labels. Hence please note that this flag renders your setup incompatible with releases before 1.5.3-rc5. 19 20 ## Batch Create Delete flag 21 22 > Available from 1.5.3 release 23 24 MIC groups operations based on nodes/VMSS during the given cycle. With `createDeleteBatch` parameter we can 25 tune the number of operations (CREATE/DELETE/UPDATE) to the API server which are performed in parallel in the context of a 26 node/VMSS. 27 28 ## Client QPS flag 29 30 > Available from 1.5.3 release 31 32 Aad-pod-identity has a new flag clientQps which can be used to control the total number of client operations performed per second 33 to the API server by MIC. 34 35 ## Block Instance Metadata flag 36 37 The Azure Metadata API includes endpoints under `/metadata/instance` which 38 provide information about the virtual machine. You can see examples of this 39 endpoint in [the Azure documentation](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service#retrieving-all-metadata-for-an-instance). 40 41 Some of the information returned by this endpoint may be considered sensitive 42 or secret. The response includes information on the operating system and image, 43 tags, resource IDs, network, and VM custom data. 44 45 This information is legitimately useful for many use cases, but also presents a 46 risk. If an attacker can exploit a vulnerability that allows them to read from 47 this endpoint, they may be able to access sensitive information even if the 48 vulnerable Pod does not use Managed Identity. 49 50 The `blockInstanceMetadata` flag for NMI will intercept any requests to this 51 endpoint from Pods which are not using host networking and return an HTTP 403 52 Forbidden response. This flag is disabled by default to maximize compatibility. 53 Users are encouraged to determine if this option is relevant and beneficial for 54 their use cases. 55 56 ## ImmutableUserMSIs flag 57 58 > Available from 1.5.4 release 59 60 Aad-pod-identity has a new flag `immutable-user-msis` which can be used to prevent deletion of specified identities from VM/VMSS. 61 The list is comma separated. Example: 00000000-0000-0000-0000-000000000000,11111111-1111-1111-1111-111111111111 62 63 ## Metadata header required flag 64 65 > Available from 1.6.0 release 66 67 > This flag is enabled by default starting from v1.8.4 release 68 69 When you query the Instance Metadata Service, you must provide the header `Metadata: true` to ensure the request was not unintentionally redirected. You can see examples of this header in [the Azure documentation](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/instance-metadata-service#using-headers). 70 71 This is critical especially when you [acquire an access token](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http) as a mitigation against Server Side Request Forgery (SSRF) attack. 72 73 The `metadataHeaderRequired` flag for NMI will block all requests without Metadata header and return an HTTP 400 response. This flag is disabled by default for compatibility, but recommended for users to enable this feature. 74 75 ## Set Retry-After header in NMI response 76 77 > Available from v1.8.2 release 78 79 NMI currently has internal retries to handle delays in the identity assignment when the pod requests for a token. In case of clients that have shorter timeouts, the retries can be terminated and the client will not receive a token in the first attempt. This feature flag when enabled will set the `Retry-After` header to 20s in the NMI response to the client and return a HTTP 503 response. The SDK used by the client will retry the request after 20s. 80 81 ### How to enable this feature 82 83 While enabling this feature, you must also disable the internal retries in NMI. 84 85 - If using the [yaml](../../getting-started/installation/#quick-install) to deploy aad-pod-identity, you can enable this feature by setting the `--set-retry-after-header=true` flag in the NMI container. 86 - Set `--retry-attempts-for-created=1`, `--retry-attempts-for-assigned=1` and `--find-identity-retry-interval=1` flags in the NMI container to disable the internal retries in NMI. 87 - If using [helm](../../getting-started/installation/#helm) to deploy aad-pod-identity, you can enable this feature by setting `nmi.setRetryAfterHeader=true` as part of helm install/upgrade. 88 - Set `nmi.retryAttemptsForCreated=1`, `nmi.retryAttemptsForAssigned=1` and `nmi.findIdentityRetryIntervalInSeconds=1` flags in the helm install/upgrade command to disable the internal retries in NMI. 89 90 ## Enable deletion of conntrack entries 91 92 > Available from v1.8.7 release 93 94 NMI redirects Instance Metadata Service (IMDS) requests to itself by setting up iptables rules after it starts running on the node. 95 However, these rules are not applicable to pre-existing connections. In such a scenario, the token request will be directly sent to IMDS instead of being intercepted by NMI. What this means is that the workload pod that runs before the NMI pod on the node can access identities that it doesn't have access to. 96 The `enable-conntrack-deletion` flag enables deletion of entries for pre-existing connections to IMDS endpoint, this causes applications which had pre-existing connections to be intercepted by NMI. 97 98 ### How to enable this feature 99 100 - If using the [yaml](../../getting-started/installation/#quick-install) to deploy aad-pod-identity, you can enable this feature by setting the `--enable-conntrack-deletion=true` flag in the NMI container. 101 - If using [helm](../../getting-started/installation/#helm) to deploy aad-pod-identity, you can enable this feature by setting `nmi.enableConntrackDeletion=true` as part of helm install/upgrade.