Example Policies
Example policies for Lenses IAM.
These are the recommended default role templates. Use them as-is or as a starting point for custom roles tailored to your organization's needs.
Lenses Agent 6.2.8 and earlier ignore service-wide wildcard resources such as kafka:*, schemas:* or alerts:*: a statement that uses one grants nothing, so lists show up empty and some pages return an error. On these versions, set the resource of such a statement to * (its actions still limit what is granted), or use typed resources such as kafka:topic:* or schemas:schema:*/*/*. Resources for iam, environments and k2k are not affected.
Administrator
Full system access with all permissions. Administrators can manage all resources, users, and system configuration. This role should be granted sparingly and only to trusted personnel.
Role
name: administrator
policy:
- action: "*"
resource: "*"
effect: allowThe admin role grants unrestricted access. Consider creating more granular roles for day-to-day operations.
Developer
Create and manage data infrastructure including topics, connectors, processors, and schemas. Developers can build and deploy data pipelines but cannot manage users or system configuration.
Role
name: developer
policy:
# Kafka topics - full management except delete
- action:
- kafka:CreateTopic
- kafka:ListTopics
- kafka:GetTopicDetails
- kafka:UpdateTopicDetails
- kafka:ReadTopicData
- kafka:WriteTopicData
- kafka:ListTopicDependants
resource: kafka:topic:*
effect: allow
# Consumer groups - view and manage
- action:
- kafka:ListConsumerGroups
- kafka:GetConsumerGroupDetails
- kafka:ListConsumerGroupDependants
resource: kafka:consumer-group:*
effect: allow
# Schemas - full management except delete
- action:
- schemas:CreateSchema
- schemas:ListSchemas
- schemas:GetSchemaDetails
- schemas:UpdateSchema
- schemas:GetRegistryConfiguration
resource: schemas:*
effect: allow
# Kafka Connect - create and manage connectors
- action:
- kafka-connect:CreateConnector
- kafka-connect:ListConnectors
- kafka-connect:GetConnectorDetails
- kafka-connect:GetConnectorConfiguration
- kafka-connect:UpdateConnectorConfiguration
- kafka-connect:StartConnector
- kafka-connect:StopConnector
- kafka-connect:ListConnectorDependants
- kafka-connect:ListClusters
- kafka-connect:GetClusterDetails
- kafka-connect:DeployConnector
resource: kafka-connect:*
effect: allow
# SQL Streaming - create and manage processors
- action:
- sql-streaming:CreateProcessor
- sql-streaming:ListProcessors
- sql-streaming:GetProcessorDetails
- sql-streaming:GetProcessorSql
- sql-streaming:UpdateProcessorSql
- sql-streaming:StartProcessor
- sql-streaming:StopProcessor
- sql-streaming:GetProcessorLogs
- sql-streaming:ListProcessorDependants
resource: sql-streaming:*
effect: allow
# Kubernetes - view and deploy
- action:
- kubernetes:ListClusters
- kubernetes:GetClusterDetails
- kubernetes:ListNamespaces
- kubernetes:DeployApps
resource: kubernetes:*
effect: allow
# Applications - register and manage
- action:
- applications:RegisterApplication
- applications:ListApplications
- applications:GetApplicationDetails
- applications:ListApplicationDependants
resource: applications:*
effect: allow
# K2K - create and manage
- action:
- k2k:CreateApp
- k2k:UpdateApp
- k2k:UpsertApp
- k2k:GetApp
- k2k:ListApps
resource: k2k:*
effect: allow
# Governance - submit requests
- action:
- governance:CreateRequest
- governance:ListRequests
- governance:GetRequestDetails
resource: governance:request:*
effect: allow
# Connections - list (the Explorer needs this to show Schema Registry and Kafka Connect)
- action:
- administration:ListConnections
resource: administration:connection:*/*
effect: allow
# Environments - view and access
- action:
- environments:ListEnvironments
- environments:GetEnvironmentDetails
- environments:AccessEnvironment
resource: environments:*
effect: allow
# Alerts - view
- action:
- alerts:ListAlertRules
- alerts:GetAlertRuleDetails
- alerts:ListAlertEvents
- alerts:ListChannels
resource: alerts:*
effect: allow
# Data policies - view
- action:
- data-policies:ListPolicies
- data-policies:GetPolicyDetails
resource: data-policies:*
effect: allowData Engineer
Read and write topic data, manage schemas, and create SQL processors. Data engineers focus on data transformation and pipeline development but have limited infrastructure management capabilities.
Role
The data_policies statements require Lenses Agent 6.3 or later with agent data policies disabled. See Data policies in IAM.
Viewer
Read-only access across all resources. Viewers can browse topics, view configurations, and monitor status but cannot make any changes. Ideal for stakeholders who need visibility without modification rights.
Role
The data_policies statements require Lenses Agent 6.3 or later with agent data policies disabled. See Data policies in IAM. The statements also apply to topic data the user reads through permissions from other roles.
Viewers cannot read topic data (kafka:ReadTopicData). Add that permission explicitly if data browsing is needed.
Operator
Operational management without create/delete permissions. Operators can start, stop, scale, and monitor resources but cannot create new infrastructure or delete existing resources.
Role
Security Administrator
IAM and security management without data access. Security admins manage users, roles, groups, service accounts, ACLs, and audit logs but cannot read or write topic data.
Role
Governance Administrator
Approve governance requests and manage data policies. Governance admins review and approve/deny self-service requests and configure governance rules and data protection policies.
Role
Governance admins need underlying permissions (e.g., kafka:CreateTopic) to approve requests that create resources.
PII Masking
Masks common personal data fields on every topic that the reader can already access. The role grants no permissions. Bind it together with the roles that grant topic access. Data policy statements require Lenses Agent 6.3 or later with agent data policies disabled. See Data policies in IAM.
Role
Analyst
Reads order topics in the prod environment with personal data masked. The masking statements apply to the same topics that the role can read.
Role
Compliance Exemption
Removes the masking of email addresses for users who must read them unmasked. The role grants no permissions. Bind it together with the roles that grant topic access and masking.
Role
A none statement removes the masking that the user's other roles apply to the same field. Bind this role only to groups that must read the field unmasked.
Environment-Scoped Roles
The roles above grant access across all environments. To restrict access to specific environments, modify the resource patterns.
Developer for specific environment
Restrict developer access to only the us-dev environment:
Role
Deny production access
Explicitly deny access to production environments:
Role
Mask data in production only
Mask email addresses in the prod environment and leave other environments unmasked:
Role
Last updated
Was this helpful?