<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Control access to Kubernetes-related data in Grail in Container platforms</title>
    <link>https://community.dynatrace.com/t5/Container-platforms/Control-access-to-Kubernetes-related-data-in-Grail/m-p/295649#M3500</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;I'm having a hard time segregating access to all data related to Kubernetes. I have an applicationMonitoring deployment with K8s observability deployment, and I need to provide access to the data to the whole K8s team.&lt;/P&gt;
&lt;P&gt;For this reason, I set up a group that has the&amp;nbsp;&lt;STRONG&gt;Standard User&lt;/STRONG&gt; and&amp;nbsp;&lt;STRONG&gt;All Grail Data Read Access&amp;nbsp;&lt;/STRONG&gt;assigned. On those policies I bound them to a boundary that filters by MZ at start. In the classic UI I get the expected visibility, but in Gen3 apps I don't get the expected visibility. I tried doing it by a security context that gets populated with the MZ, but still there are gaps, like in the Problems app or the traces.&lt;/P&gt;
&lt;P&gt;In general, it seems quite complex to implement a unified way of fine-tune these kind of accesses.&lt;/P&gt;
&lt;P&gt;Does anyone have any experience with this issue before?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;George&lt;/P&gt;</description>
    <pubDate>Thu, 05 Mar 2026 07:39:33 GMT</pubDate>
    <dc:creator>g_kat</dc:creator>
    <dc:date>2026-03-05T07:39:33Z</dc:date>
    <item>
      <title>Control access to Kubernetes-related data in Grail</title>
      <link>https://community.dynatrace.com/t5/Container-platforms/Control-access-to-Kubernetes-related-data-in-Grail/m-p/295649#M3500</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;
&lt;P&gt;I'm having a hard time segregating access to all data related to Kubernetes. I have an applicationMonitoring deployment with K8s observability deployment, and I need to provide access to the data to the whole K8s team.&lt;/P&gt;
&lt;P&gt;For this reason, I set up a group that has the&amp;nbsp;&lt;STRONG&gt;Standard User&lt;/STRONG&gt; and&amp;nbsp;&lt;STRONG&gt;All Grail Data Read Access&amp;nbsp;&lt;/STRONG&gt;assigned. On those policies I bound them to a boundary that filters by MZ at start. In the classic UI I get the expected visibility, but in Gen3 apps I don't get the expected visibility. I tried doing it by a security context that gets populated with the MZ, but still there are gaps, like in the Problems app or the traces.&lt;/P&gt;
&lt;P&gt;In general, it seems quite complex to implement a unified way of fine-tune these kind of accesses.&lt;/P&gt;
&lt;P&gt;Does anyone have any experience with this issue before?&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;Thanks,&lt;/P&gt;
&lt;P&gt;George&lt;/P&gt;</description>
      <pubDate>Thu, 05 Mar 2026 07:39:33 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Container-platforms/Control-access-to-Kubernetes-related-data-in-Grail/m-p/295649#M3500</guid>
      <dc:creator>g_kat</dc:creator>
      <dc:date>2026-03-05T07:39:33Z</dc:date>
    </item>
    <item>
      <title>Re: Control access to Kubernetes-related data in Grail</title>
      <link>https://community.dynatrace.com/t5/Container-platforms/Control-access-to-Kubernetes-related-data-in-Grail/m-p/296172#M3506</link>
      <description>&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hi,&lt;BR /&gt;yes, I’ve seen this issue before, and in my opinion the main challenge is that in Classic/Management, access is often scoped through Management Zones, where visibility is defined using entity selectors.&lt;/P&gt;&lt;P&gt;In the new apps, however, access is primarily evaluated based on permission-relevant fields and optionally dt.security_context, not only on classic entity visibility. Dynatrace supports Kubernetes-related fields such as k8s.cluster.name and k8s.namespace.name, so for a Kubernetes team this is usually a better foundation for access policies.&lt;/P&gt;&lt;P&gt;That also explains why everything may look correct in the Classic UI, while you still see gaps in Gen3 apps, for example in Problems or Distributed Tracing. Problems are stored in Grail as events, and tracing plus other Grail data types rely on the permission model based on security context and permission-relevant fields. If the records themselves are not enriched with the expected context, the policy cannot enforce the scope the way you want.&lt;/P&gt;&lt;P&gt;So I would recommend this approach:&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;build access mainly around native Kubernetes fields in Grail&lt;/LI&gt;&lt;LI&gt;use dt.security_context only where you need an extra abstraction layer&lt;/LI&gt;&lt;/UL&gt;&lt;P&gt;&lt;BR /&gt;U can also try use our policy calculator:&amp;nbsp;&lt;A href="https://omnilogy.pl/en/policy-manager" target="_self"&gt;Dynatrace policy calculator&lt;/A&gt;&amp;nbsp;&lt;BR /&gt;Here you can also find a related post:&amp;nbsp;&lt;A href="https://community.dynatrace.com/t5/Custom-Solutions-Spotlight/Dynatrace-Policy-Manager/td-p/288993" target="_self"&gt;Dynatrace-Policy-Manager&lt;/A&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Sat, 14 Mar 2026 21:06:20 GMT</pubDate>
      <guid>https://community.dynatrace.com/t5/Container-platforms/Control-access-to-Kubernetes-related-data-in-Grail/m-p/296172#M3506</guid>
      <dc:creator>t_pawlak</dc:creator>
      <dc:date>2026-03-14T21:06:20Z</dc:date>
    </item>
  </channel>
</rss>

