Skip to main content

Intro: ChatOps

One-Click Least Privilege. Zero Disruption.



© 2025 Sonrai Security. All rights reserved.

Overview​

Before ChatOps integration, receiving notifications and managing Permission on Demand (POD) requests often involved multiple tools. First, approvers would receive email notifications when Permissions on Demand requests were triggered. Then, they would use the Requests page in Cloud Permissions Firewall to view and act on POD requests.

tip
Learn more about managing requests here.

ChatOps integration streamlines this process, allowing you to receive notifications and react immediately to Permissions on Demand (POD) requests from a single tools, using either Slack or Teams. ChatOps also makes proactive requests for just-in-time (JIT) access as easy as sending a chat message!

Configuring ChatOps doesn't prevent you from receiving email notifications or managing requests in the Sonrai Cloud Permissions Firewall app. Choose the method that works best for your team, whether that involves one method of communication or a combination of options!

ChatOps integration​

Configure your Slack integration

Learn more about Slack workflows

Configure your Teams integration

Learn more about Teams workflows


Alternate Identity Mapping for ChatOps Notifications​​

Many organizations use single sign-on (SSO) to simplify access across systems — with development environments, CRM platforms, and collaboration tools like Slack or Microsoft Teams all tied to a single identity. However, some cloud administrators may use a different account to manage their cloud platform, with elevated permissions compared to their standard SSO credentials.

If you log into Slack with your standard work identity, but access AWS with a different identity that provides additional permissions, then Permissions on Demand (POD) requests or just-in-time (JIT) access notifications will not reach you unless the two identities are linked. Identity Mapping resolves this mismatch.

How Identity Mapping Works​

Identity Mapping uses a GraphQL query to add and configure a pond_upn_replace_key key, which specifies the field in AWS IAM Identity Center records where alternate ChatOps identities are stored. The alternate identity field should be an existing but unused field in the Identity Store User object (such as "Locale" or "Nickname").

Cloud Permissions Firewall then looks at this field when resolving POD and JIT requests, and ensures that request justifications are sent to the appropriate ChatOps user.

  • If pond_upn_replace_key does not exist or is set to the default value ("0"), then ChatOps notifications are handled as usual.
  • If pond_upn_replace_key specifies a field, then Cloud Permissions Firewall checks that field for SSO users and uses the alternate address stored there to deliver ChatOps notifications.
tip

Learn more about using Sonrai's GraphQL API Library.

Configure Identity Mapping​

  1. To enable Identity Mapping, use the Explorer screen or Sonrai GraphQL API to perform the following update:
mutation setIdentityMapping {
  CreateCPFConfig(
    cpfConfig: {
      key: "pond_upn_replace_key"
      value: "$.user.<fieldname>"
      defaultValue: "0"
    }
  ) {
    success
  }
}
  1. Once enabled, populate the chosen field in AWS with alternate identities that your admin users will use for ChatOps login. For example, if using the Nickname field then an admin user might look something like this:

Once this feature is enabled, Cloud Permission Firewall will pick up the changes to your AWS user profiles within 24 hours and start routing POD and JIT requests to the specified identities.

info

To disable Identity Mapping and restore default behavior for notifications, do not remove the new fields. Instead, simply set the value of pond_upn_replace_key to zero ("0").

Verify Identity Mapping​

Use this GraphQL query to verify that Identity Mapping is enabled:

query listconfigs {
  CPFConfigs(where: { key: { op: EQ, value: "pond_upn_replace_key" } }) {
    count
    items {
      key
      value
      defaultValue
    }
  }
}

Use this GraphQL query to check all identities for alternate mappings:

query checkIdentityMappings {
  ListResourceSummaries(
    where: {
      serviceType: { op: EQ, value: "sso" }
      type: { op: EQ, value: "SAML" }
    }
  ) {
    Identities: totalCount
    items {
      account
      resourceId
      lastUsedDate
      name
      identityMapping: metadata @jsonPath(path: "user.<fieldname>")
    }
  }
}
Last updated on