You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The attribute dt.security_context is important for data segmentation, analysis, and permission mapping within the Dynatrace platform. Currently, the dynatrace-gcp-monitor does not set or define this attribute on the metrics and logs sent from this integration. As a result, by default, the dt.security_context attribute cannot be used. As a workaround, processing rules in the Dynatrace environment can be configured to parse data and apply a value to dt.security_context. However, this requires elevated access to the Dynatrace environment and hinders self-service deployment and adoption of Dynatrace for GCP.
Describe the solution you'd like
As a first step, setting the dt.security_context to a static value during the helm chart deployment should be possible by specifying the desired value in the values.yaml. This should apply the desired dt.security_context attribute to all logs and metric dimensions sent from the dynatrace-gcp-monitor to Dynatrace.
A better solution, would be to allow specifying an existing attribute as a dynamic value passed as the dt.security_context. For example, in the values.yaml, having a setting called securityContext with a value like fromAttribute: gcp.project.id would set the value of dt.security_context as the same value of gcp.project.id.
securityContext:
fromAttribute: 'gcp.project.id' # set the value equal to that of gcp.project.id if it exists
default: 'my default context' # set the value to 'my default context' if the value of 'gcp.project.id' does not exist
Is your feature request related to a problem? Please describe.
The attribute
dt.security_context
is important for data segmentation, analysis, and permission mapping within the Dynatrace platform. Currently, thedynatrace-gcp-monitor
does not set or define this attribute on the metrics and logs sent from this integration. As a result, by default, thedt.security_context
attribute cannot be used. As a workaround, processing rules in the Dynatrace environment can be configured to parse data and apply a value todt.security_context
. However, this requires elevated access to the Dynatrace environment and hinders self-service deployment and adoption of Dynatrace for GCP.Describe the solution you'd like
As a first step, setting the
dt.security_context
to a static value during the helm chart deployment should be possible by specifying the desired value in thevalues.yaml
. This should apply the desireddt.security_context
attribute to all logs and metric dimensions sent from thedynatrace-gcp-monitor
to Dynatrace.A better solution, would be to allow specifying an existing attribute as a dynamic value passed as the
dt.security_context
. For example, in thevalues.yaml
, having a setting calledsecurityContext
with a value likefromAttribute: gcp.project.id
would set the value ofdt.security_context
as the same value ofgcp.project.id
.securityContext:
fromAttribute: 'gcp.project.id' # set the value equal to that of gcp.project.id if it exists
default: 'my default context' # set the value to 'my default context' if the value of 'gcp.project.id' does not exist
Describe alternatives you've considered
See above
Additional context
https://docs.dynatrace.com/docs/observe-and-explore/logs/lma-security-context
The text was updated successfully, but these errors were encountered: