BotFactory

BotFactory Overview

Botfactory is a simple rules engine allowing for “If this, then that” (IFTTT) style automation orchestration. The goal of Botfactory is to provide a low barrier of entry to scanning or reacting to change in an organization’s cloud infrastructure. During Botfactory’s early stages of prototyping and development of the user experience we want to provide some extra insight into how control logic in Botfactory works.

Back To Top

Components: scope, conditions and actions

Components: scope, conditions and actions

BotFactory contains several components which comprise the system. These are the bot scope, the conditions (aka filters), actions and when the bot should run.

Back To Top

Scope

Every bot has several properties that define its scope. Scope describes what resources the bot will evaluate. For example, a bot may have its scope confined to only those resources of a certain type. It may also have its scope confined to only those resources contained within one or more resource groups or cloud accounts.

Back To Top

Conditions

Conditions specify the IFT part of IFTTT automation. This is how you configure what a bot should act on. As an example a condition may match each resource based on tags that it does or does not have. It may match based on which ports are or are or are not open. There are numerous conditions included with BotFactory, and it is possible for a programmer to define their own.

Back To Top

Actions

An action may delete a resource, it may start or stop an instance, it may send an email containing information about the evaluated resource. Every action serves a different purpose, and there are numerous actions included with Botfactory. As with conditions, it is possible for a programmer to define their own actions.

In the first step of evaluation, described by conditions, a resource is determined to be a match or not-match. This result affects the behavior of the second step of evaluation, described by actions. Each action may evaluate only matching resources or only not-matching resources. Most commonly, a bot will only need actions which evaluate only matches or only not-matches. It is also possible, however, for a bot to contain a combination of such actions, where some actions evaluate matches and others evaluate not-matches.

Actions are evaluated for a single resource at a time. When a bot possesses multiple actions they are evaluated in-order for a single resource. Each action can be evaluated either for resources that match or for those that do not. Actions set to evaluate matching resources are evaluated for every resource which meets all of the conditions for that bot. Actions set to evaluate not-matching resources are evaluated for every resource in the bot’s scope that did not meet every condition. For the majority of cases this can be expressed as a simple rule of thumb: If a bot’s conditions describe an actionable resource, then the actions should evaluate matching resources; if a bot’s conditions describe all other resources – that is, those that are not actionable, to the exclusion of all others – then the actions should evaluate not-matching resources.

Back To Top

Evaluation

For example, a bot with intended to take remedial action for resources that are in an unwanted state could be structured in one of two ways. The bot could have conditions which describe the problematic resources, and its remedial action would evaluate matching resources. Alternatively, the bot could have conditions which describe resources in an acceptable state, and its remedial action would evaluate not-matching resources.

action_example

Back To Top

Condition Negation

Every bot has several properties that define its scope. Scope describes what resources the bot will evaluate. For example, a bot may have its scope confined to only those resources of a certain type. It may also have its scope confined to only those resources contained within one or more resource groups or cloud accounts.

Back To Top

Creation

Creation Overview

Bot Factory is DivvyCloud’s answer to easy policy automation. The user is able to select from a list of predefined conditions, which match resources, and actions, which act upon those resources. If the predefined conditions and actions aren’t sufficient for a user’s needs, it’s possible to create new conditions and actions which provide the needed functionality.

Back To Top

Creating a Bot

Bots are created through DivvyCloud’s web interface. The bots page includes a “Create Bot” button which, when clicked, brings the user to the bot creation dialog. Here the bot is assigned a name, description, and category. The user determines which resources are within the scope of this new bot – that is, resources that the bot will filter and act against – and then chooses and configures the bot’s conditions and actions. A single bot may have more than one condition associated with it, and a resource is only matched if all of the bot’s conditions match that resource. A bot may also have multiple actions, some whch are executed when a bot’s conditions all match and other, complementary actions that execute when any don’t match. When multiple actions are assigned to either outcome, the actions for that outcome are executed in series: The topmost action occurs first and then, when it has finished, the following action is executed, and so on until the list of actions has been fully traversed.

There is, for example, the “Resource Has Tags” condition. When selected, a configurable view of that condition appears in the bot’s list of conditions. It has configurable fields, including a list of tags. If the tags “hello” and “world” were entered as this condition’s tags, then the bot would match resources with both of those tags, and not match resources without both tags.

The user could then add another condition to the same bot. As a consequence, the created bot would match only resources that matched both the tags flter and the additional filter. It would not match resources that failed to match either filter.

Once conditions have been assigned, the user selects actions to be run when the bot matches or does not match a resource. There is, for example, the “Send Email” action. If this action was assigned to run when all of the bot’s conditions matched a resource, and if the action’s configuration was filled out using an email subject, body, send, and recipients, then every time a resource possessed both the tags “hello” and “world” such an email would be sent.

Back To Top

Creating Conditions and Actions

Conditions and actions are defined within Plugins. In a plugin’s python script, conditions and actions can be registered with the DivvyCloud application using the BotFactoryRegistryWrapper imported from DivvyBotFactory.registry. A registry wrapper must first be instantiated, and then it can be used to decorate python functions as conditions (internally referred to as filters) and actions.

Every filter and action function accepts three arguments, event, bot, and settings. The event argument represents an event that the bot is responding to, such as a hookpoint or a resource found during a retroactive scan. Most remarkable is its event.resource attribute, which refers to the resource being evaluated by the bot. The bot argument provides the bot object that this filter or action is running as a part of. Finally, the settings argument is a dictionary of keys and values representing user input given when the bot was created. The keys correspond to fields provided in the supported_resources argument of a filter or action, the values to what the user inputted for those fields.

The settings argument should not be modified inside of a filter or action. It is not recommended to modify any of the arguments passed to a filter. Filters written for the core DivvyCloud application are created with the principle in mind that filters should not have side-effects. That is, they should analyze state but not modify it.

Here’s an example of how DivvyCloud’s Bot Factory plugin registers the predefined “Log Message” action, which logs a line of text to the console:

# Instantiate an object for interfacing with the bot filter and action registries
from DivvyBotFactory.registry import BotFactoryRegistryWrapper
registry = BotFactoryRegistryWrapper()

# Define the action
@registry.action(
    uid='divvy.action.log_message',
    name='Log Message',
    description='Log an info message, intended to aid developers in testing.',
    author='DivvyCloud Inc.',
    supported_resources=[],
        settings_config=[
        StringField(  # Configuration field to appear in the bot creation form
            name='message_text',
            display_name='Message To Log',
            description='Message text to log when this action is evaluated.',
            preselected_values='Action evaluated'
        )
    ]
)
def log_message(event, bot, settings):
    logger.info('{0}: {1}'.format(
        event.resource.resource_id,  # Unique ID belonging to the resource being acted upon
        settings.get('message_text', 'Unspecified message')
    ))

# Register and unregister this action along with the containing plugin
def load():
    registry.load()
def unload():
    registry.unload()

The registry object instantiation needs to take place only once in a python script registering actions and filters, as well as plugin loading and unloading.

The registry filter and action decorators pass their arguments through to the BotFactoryFunction constructor, which accepts various fields of metadata to associate with the registered functions.

This is how the Bot Factory plugin registers the predefined SSL expiration filter:

from DivvyBotFactory.registry import BotFactoryRegistryWrapper
registry = BotFactoryRegistryWrapper()

@registry.filter(
    uid='divvy.filter.expiring_ssl_certificates',
    name='Identify Expired/Expiring SSL Certificates',
    description=(
        'Match SSL certificates depending on whether their expiration date is '
        'within a specified number of days.'
    ),
    author='DivvyCloud Inc.',
    # Limit the resources types that this filter may apply to
    supported_resources=[ResourceType.SERVICE_CERTIFICATE],
    settings_config=[
        IntegerField(  # Numeric field to appear in the bot creation form
            name='days',
            display_name='Days',
            description=(
                'How many days out to flag certificates as upcoming on expiration.'
            ),
            options=FieldOptions.REQUIRED
        )
    ]
)
def expiring_ssl_certificates(event, bot, settings):
    expiration_time = datetime.utcnow() + timedelta(days=settings.get('days', 14))
    return event.resource.expiration_date < expiration_time

def load():
    registry.load()
def unload():
    registry.unload()

Conditions and actions registered in this way, in plugins that are recognized and loaded by the DivvyCloud application, will appear in the condition and actions lists when creating bots.

Back To Top

Creating Trackers

Trackers are an important technical concept intended primarily to support the function of actions. They provide context for actions and filters to share and utilize. For example, an action is provided with the DivvyCloud application which adds acted-upon resources to a resource group.

Its registration and function signature looks like this:

@registry.action(
    uid='divvy.action.add_resource_to_group',
    name='Add To Resource Group',
    description='Add resources to a group.',
    author='DivvyCloud Inc.',
    supported_resources=[],
    required_trackers={'divvy.curation': CurationTracker},  # Take note
    settings_config=[
        ...
    ]
)
def bot_add_resource_to_group(event, bot, settings):
    ...

Its body contains a line like this:

event.trackers['divvy.curation'].add_resource(event, resource_group_id)

Using the required_trackers argument, Botfactory can be notified that a given tracker must be present in order for a filter or action to function correctly. The keys of the passed dictionary represent tracker names, which should be unique identifiers, and each value should be any callable that returns a valid tracker object. That tracker is referenced using the trackers dictionary of the object passed in via a filter or action’s event argument.

Several actions may share the same tracker; for example, there are multiple actions in the DivvyCloud application that use the CurationTracker referenced here. All of them specify the same required_trackers argument, and if more than one of those actions is evaluated in a single bot evaluation context, those differing actions will still share the same instance of the “CurationTracker` class.

If another action defined its own required_trackers with the same key, divvy.curation, but a different initialization function, then an error would occur.

But what is a tracker?

Trackers accumulate a queue of state changes, and that queue is flushed every so often. They allow callbacks, such as methods that execute at the beginning and end of a bot execution context.

In the above example, the add_resource method of the CurationTracker object performs some behavior unique to that tracker class. It adds the detauls of a curated resource to a queue, and when the tracker is flushed it sends an insertion query to the database which at once makes all of the updates in that queue.

In order for an object to be recognized as a tracker, it must implement persist, reset, and __len__ methods. The persist method flushes the queue of actions, and is called whenever a batch size is met or when a bot execution context is concluded and there are still items in the queue. The reset method empties the queue, typically after the queue has been persisted. And the __len__ method informs the bot execution context of how many items are currently in the queue.

This is what the CurationTracker class looks like:

Back To Top

Bot States & Lifecycle Actions

Bot States & Lifecycle Actions

Bots have several states and actions which are available to end-users. Please take a look at the information below.

Back To Top

States

Bot states are controlled via the action menu. Simply select one or more bots from the listing to transition them to the desired state.

  • Running: This state denotes that a bot is operational and is functioning on select hookpoints and/or schedule
  • Paused: The bot is in a suspended state and is not taking action. This state is typically found on newly created bots and/or bots which are in development
  • Archived: The bot is no longer in-use, but is kept around for historical/auditing purposes
  • Scanning: The bot is currently performing a retroactive scan of the configured scope

Back To Top

Lifecycle Actions

The following lifecycle actions can be taken against existing bots:

  • Resume: This action will transition a paused/suspended bot to a running state. Any hookpoints and schedules configured will be used as the bot’s execution point.
  • Pause: Suspend a running bot. Typically this is done on newly created bots or bots that you want to suspend for maintenance.
  • Archive: Permanently disable a bot. The bot’s history and metadata is kept for historical purposes; however, scheduled events and noncompliance data will be purged.
  • Edit Bot: The bot scope is immutable; however, you can modify the filters/actions, schedule and hookpoints. If you need to modify bot scope, you will want to make a copy.
  • Copy Bot: Copy the configuration of one bot to another to simplify creation. This is typically desired when changes to bot scope are needed.
  • Retroactive Scan: Run a scan against all known resources within the configured scope. Typically this is desired when you want to retroactively audit/enforce policy.

Back To Top

Resource Group Curation

In/Out Curation

BotFactory ships with an action named Curate Resource Group, which when added to a bot’s instruction set will assume responsibility for maintaining the state of the resource group. It is important to note that this action can be used only as a one-to-one relationship between a single bot and single group. The bot will autonomously move resources in and out of the group as needed based on the configured policy.

Back To Top

Add Only Curation

Occasionally end-users may need multiple bots to add resources into a group. In this scenario there is a bot action named Add To Group. As the name implies, this action will only add to a group, and will not automatically remove resources which no longer apply. This method of curation can be good in scenarios where there are numerous bots and users adding resources into the group.

Back To Top

Examples

Let’s go ahead and work through an in/out curation policy as an example. For this example we are going to build a resource group named Production Resources which will include resources with the tag “environment” and a value of “production”. The scope of the bot will inspect resources across Micorosft Azure, Amazon Web Services and Google Compute Engine.

1.) Create a new resource group

Navigate to the Groups section of the tool and create a new shared group. We will name it Production Resources for this example. Refer to the image for reference.

curate_step_1

2.) Create a new bot

Click on the Create Bot button and enter the name, description and category. Refer to the image below for reference.

curate_step_2

3.) Configure scope

The scope defines the resource type(s) and cloud account(s) you want to inspect. For this example we will audit billable resource types such as instances, database instances (eg: AWS RDS), volumes and snapshots. We will inspect three cloud accounts. Note that if we selected Scan All Groups it would scan every configured cloud account.

curate_step_3

4.) Configure Conditions

Conditions can be as simple or complex as you want them to be. For this example, we will use a single condition which inspects resource tag values and looks for the keyEnvironment with a value of Production. You can include as many values as you want in the form, but for this example we will only look for the value Production. Note that if you check the Case Sensitive box it will enforce case sensitivity.

curate_step_4

5.) Configure Actions

Similar to conditions, bot authors can stitch together as many actions as they want. The action we are going to use for this example is Curate Resource. Select that from the listing and then use the select dropdown to select the desired group.

curate_step_5

6.) When to run

The final step of the process identifies when you want the bot to run. For this type of bot, it is recommended to listen on the resource created and resource modified. With this approach anytime a new resource is spun up in the cloud, or the tags are modified the bot will inspect to see if it meets this criteria. Also, by enabling batch execution a bot author can perform a retroactive scan to build the group out based on previously discovered resources.

curate_step_6

7.) Save the bot

You can now save the bot. Once done you can resume the bot and perform a retroactive scan. If you have resources which meet the configured conditions, they should show up in theProduction Resources group.

Back To Top

Scheduled Events

Scheduled Events

The DivvyCloud application provides a mechanism for running a job at a specified time with specified arguments. Such a job is referred to as a scheduled event, and these scheduled events can be spawned by bots to perform some action at a later time.

A job is registered as a scheduled event using the register method of the ScheduledEventManagerclass, which acts as a class decorator. For example, this is how the StartResourceJob scheduled event is registered in the DivvyCloud application:

from DivvyWorkers.Processors.ScheduledEvents import ScheduledEventManager
@ScheduledEventManager.register('divvy.start_resource')
class StartResourceJob(MultiResourceScheduledEventJob):
    ...

The scheduled event can then be referred to using the unique identifier defined in the register decorator, in this case divvy.start_resource.

Here’s an example implementation for how to spawn such an event from within a bot action:

@registry.action(
    uid='divvy.action.start_resource_example',
    required_trackers={'divvy.scheduling': ScheduledEventTracker},
    ...
)
def start_resource_example(event, bot, settings):
    event.trackers['divvy.scheduling'].schedule_bot_event(
        bot=bot, event=event,
        description='Start a resource.',
        event_type='divvy.start_resource'
        schedule_data=schedule.Once(when=datetime.utcnow() + timedelta(hours=12))
    )

Back To Top

Templates

Templates

BotFactory ships with over 100 pre-created bot templates which mitigate ramp up time. You can leverage these templates within the BotFactory UI to simply bot creation and management. Listed below are the templates that ship with version 16.06 of our software

Name Category Description
Clouds With Active Root Account Best Practices Identify accounts which still have the root account active
Clouds With Weak Password Policy Best Practices Identify accounts with a weak/missing password policy
Clouds Without Protected Root Account Best Practices Identify accounts which still have the root account and it is not two-factor enabled
Clouds Without Global API Accounting Security Identifies accounts with API accounting such as AWS CloudTrail inactive/disabled across all regions
Audit Security Rules Security Identify select ports such as SSH open to the world
Database is Multi-AZ Best Practices Ensures that databases are configured across multiple availablity zones for resiliency
Database Retention Policy Best Practices Identifies database instances with a retention policy that is too low
Database Instance Publicly Accessible Security Identify database instances which are accessible to the public
Database Instance Encrypted Security Identify database instances which are not encrypted
Database Recently Snapshot Best Practices Identifies database instances with a recent manual snapshot
Database Instance Username Audit Security Identify database instances running noncompliant usernames for the master account
Scheduled Instances Optimization Scheduled instance stop/start across one or more clouds/resource groups
Resource Group Curation Curation Curate target resources into one or more resource groups
Region Audit Security Audit select resource types across specific cloud regions
Clouds Without Service Users Best Practices Identifies accounts without any active service users
Compute Instance Type Audit Best Practices Audit compute instance types against select clouds
Instance Has Ephemeral Root Volume Optimization Match instances with an ephemeral root volume
Instance Running Unauthorized Image Best Practices Match instances which were created with an unauthorized image
Instance Using Unauthorized Root Key Pair Security Match instances based on the SSH key pair they were created with
Instance Has Ephemeral Public IP Optimization Match instances with an ephemeral public facing IP address
Instance With Failed Status Checks Best Practices Match instances which fail the system/reachability status checks
Instance With No Name Best Practices Match instances which have not been supplied a name
Database Instance Type Audit Optimization Audit database instance types against select clouds
Memcache Instance Type Audit Optimization Audit memcache instance types against select clouds
Expired SSL Certificates Security Identify expired/soon to expire SSL certificates
Tag Audit Best Practices Enforce tagging standards and policy across select resource types
S3 Bucket Max Objects Optimization Identify buckets which exceed a total of 10,000 objects
S3 Bucket Max Size Optimization Identify buckets which exceed a total size of 1TB
S3 Bucket Permissions Security Identify buckets exposing data with permissive access lists
Unattached Volumes Optimization Identifies unattached volumes
Orphaned Public IP addresses Optimization Identifies unattached IP addresses which can incur cost
Ensure MFA enabled on user accounts Security Identify cloud users without two-factor (MFA) enabled
Load Balancer Access Logging Disabled Security Match all Load Balancers that have access logging disabled
Load Balancer Cross Zone Balancing Disabled Best Practices Match all Load Balancers that have cross zone balancing disabled
Load Balancer Connection Draining Disabled Best Practices Match all Load Balancers that have connection draining disabled
Load balancers with no instances Optimization Identifies orphaned load balancers with no instance associations
Database Engine Types Best Practices Identify unsupported/blacklisted database engines
S3 buckets with no permissions Security Identifies buckets without any permission sets
Subnet CIDR exceeds maximum netblock Optimization Identify subnets where the number of IP’s exceeds a defined limit
Subnet Running Out Of Space Best Practices Identify subnets with less than 10% of their block available for use
Orphaned Security Groups Security Security groups unattached to instances
S3 Bucket Global ACL Permission Security Identify buckets exposing access list permissions to the world
S3 Bucket Global Delete Permission Security Identify buckets exposing delete permissions to the world
S3 Bucket Global Read (GET) Permission Security Identify buckets exposing read permissions to the world
S3 Bucket Global Write (PUT) Permission Security Identify buckets exposing write permissions to the world
S3 Bucket Versioning Security Identify buckets without object versioning enabled
S3 Bucket Logging Security Identify buckets without logging enabled
Redshift Username Audit Security Identify Redshift instances running noncompliant usernames for the master account
Redshift Instance Audit Optimization Identify Redshift instances running unapproved instance types
Redshift Encryption Enabled Security Identify Redshift instances which do not have encryption enabled
Redshift Publicly Accessible Security Identify Redshift instances which are accessible to the public
Redshift Retention Policy Security Identify Redshift instances with a retention policy less than or equal to 30 days
Global CIFS port open to the world Security Identify TCP/UDP port 445 open to the world
Global DNS ports open to the world Security Identify TCP/UDP port 53 open to the world
Global FTP (Security Group/Network ACL Rules) Security Identify TCP port 21 open to the world
Global ICMP open to the world Security Identify ICMP open to the world
Global Microsoft SQL (Security Group/Network ACL Rules) Security Identify TCP port 1443 open to the world
Global MySQL (Security Group/Network ACL Rules) Security Identify TCP port 3306 open to the world
Globally Accessible NetBIOS Security Identify UDP 137/138 open to the world
Global Non-Web Ports Security Identify TCP ports other than 80/443 open to the world
Global PostgresSQL (Security Group/Network ACL Rules) Security Identify TCP port 5432 open to the world
Globally Accessible Administrative Port: Windows RDP Security Identify TCP port 3389 open to the world
Globally Accessible Administrative Port: Windows RPC Security Identify TCP port 135 open to the world
Globally Accessible Administrative Port: SMB over TCP Security Identify TCP port 445 open to the world
Global SMTP Access Security Identify TCP port 25 open to the world
Global SQL Server Security Identify TCP port 1433/1434 open to the world
Global SSH Access Security Identify TCP port 22 open to the world
Global Telnet Access Security Identify TCP port 23 open to the world
Global VNC Listener Access Security Identify TCP port 5500 open to the world
Global VNC Server Access Security Identify TCP port 5900 open to the world
Snapshots older than 30 days Optimization Identify snapshots which are older than 30 days
Snapshots older than 60 days Optimization Identify snapshots which are older than 60 days
Snapshots older than 90 days Optimization Identify snapshots which are older than 90 days
Volume Auto-Termination Best Practices Identify volumes set to automatically delete when the parent instance is terminated
Volumes without encryption enabled Optimization Identify volumes without encryption enabled
Excessive Volume IOPS Optimization Identify volumes with an excessively high number of IOPS
Volume Type Audit Best Practices Identify volumes running unapproved types
Volumes Without A Recent Snapshot Optimization Identify volumes without a snapshot in the past fourteen days
Cloud User Policy Audit Best Practices Identify cloud users running unauthorized policies
Cloud User Activity Audit Best Practices Identify inactive cloud users who have not logged in recently
Cloud User API Key Audit Best Practices Identify cloud users with API key credentials which should be rotated
Networks Without Internet Access Best Practices Identify networks without an attached Internet gateway
Region Without Default Network Best Practices Match regions without a default network
Region With Impaired Availability Zone Best Practices Match regions with one or more zones in an impaired state
Hypervisors With No Instances Optimization Hypervisors which are orphaned and contain zero instances
Hypervisors Not In Service Optimization Match hypervisors which are not in a functional state
Hypervisors Nearing Saturation Optimization Match hypervisors with at most the supplied percentage for instance usage
SSL Certificate Heartbleed Vulnerability Security Identify SSL certificates which may be vulnerable to SSL Heartbleed
Resource Age Check Best Practices Identify resources based on their age/creation date
Region Volume Capacity Audit Optimization Match regions within 80% or more of the volume threshold
Region Storage Container Capacity Audit Optimization Match regions within 80% or more of the storage container threshold
Region Snapshot Capacity Audit Optimization Match regions within 80% or more of the snapshot threshold
Region Security Group Audit Optimization Match regions within 80% or more of the security group threshold
Region Public IP Audit Optimization Match regions within 80% or more of the public IP threshold
Region Private Network Audit Optimization Match regions within 80% or more of the private network threshold
Region Internet Gateway Audit Optimization Match regions within 80% or more of the Internet gateway threshold
Region Compute Instance Audit Optimization Match regions within 80% or more of the compute instance threshold
Region Database Instance Audit Optimization Match regions within 80% or more of the database instance threshold
Region Cache Instance Audit Optimization Match regions within 80% or more of the cache instance threshold
Region Resource Audit Optimization Match regions within 80% or more of the threshold for any resource type

Back To Top

Frequently Asked Questions

What is a Bot?

A bot is a piece of automation code directed at cloud infrastructure resources. A bot is often designed from a template and customized to a customer’s specific needs.

Back To Top

What Does A Bot Include?

  • Metadata: name, who created it, when
  • Scope: resources analyzed and cloud account(s) targeted
  • Conditions: filters to determine which resource(s) match for the bot, such as instances of a certain type or in a certain location, networks with certain configurations, etc.

Back To Top

What is a cloud resource?

A resource refers to any bit of cloud infrastructure. This will typically include instances (virtual machines), network assets (virtual private clouds/networks – VPC/VPN), storage assets (block storage volumes or object storage containers), users, access control lists, and more.

Back To Top

What is BotFactory.io versus BotFactory in DivvyCloud?

BotFactory.io is the leading hosted platform for building and executing a collection of bots.

Back To Top

How do I connect an Amazon Web Services (AWS) account to BotFactory.io?

  1. Log in to your BotFactory.io account.
  2. Click on Add Cloud Account
  3. Choose your authentication method – IAM or STS (Security Token Service)
  4. Follow the AWS instructions to create a user with the desired role and policy on AWS Identity and Access Management (IAM) account and optionally to create the STS role assumption rule. Recommended default role is Power User. If you want to use a specific policy, please use the policy included here.
  5. Enter the required information: account number, and authentication credentials from the previous steps.
  6. Click Save
  7. BotFactory.io will start pervasive discovery of your cloud resources in your AWS account. The resources will be visible within approximately 20-30 minutes.

Back To Top

How do I create a Bot?

  1. Go to BotFactory.io.
  2. Choose BotFactory from the left navigation.
  3. Click on Templates.
  4. Choose the relevant template and click the Launch icon, which is in the shape of a square with an arrow, and appears to the left of the template name.

Back To Top

My Bot isn’t picking up the resources I expected. What do I do?

  1. Click the configuration icon (3 horizontal lines) next to the name of the bot.
  2. Choose Reconfigure.
  3. Click on Conditions in the top navigation of the bot configuration.
  4. Revise the conditions you have chosen.

Back To Top

Most conditions seem to use a “blacklist” approach, meaning finding my non-compliant resources. How do I change that to a “whitelist” approach?

There are 2 options:

  • In the Conditions section of the bot configuration, find the condition that you wish to change from blacklist to whitelist, and click the Negate box.

Or:

  • In the Actions section of the bot configuration, instead of adding actions to the Matching section, add actions to the non-matching section.

Back To Top

What AWS policy do I need on my cloud account?

Ultimately, this is your decision. However, if you want to enable the full power of BotFactory.io on your account, this policy will be most beneficial:

"Version" : "2012-10-17",

  "Statement" : [
    {
      "Action" : "ec2:*",
      "Effect" : "Allow",
      "Resource" : "*"
    },

    {
      "Effect" : "Allow",
      "Action" : "elasticloadbalancing:*",
      "Resource" : "*"
    },

    {
      "Effect" : "Allow",
      "Action" : "cloudwatch:*",
      "Resource" : "*"
    },

    {
      "Effect" : "Allow",
      "Action" : "rds:*",
      "Resource" : "*"
    },

        {
      "Action" : "redshift:*",
      "Effect" : "Allow",
      "Resource" : "*"
    },

        {
      "Action" : "s3:*",
      "Effect" : "Allow",
      "Resource" : "*"
    },

        {
      "Action" : "iam:*",
      "Effect" : "Allow",
      "Resource" : "*"
    },

        {
      "Action" : "route53:*",
      "Effect" : "Allow",
      "Resource" : "*"
    },

        {
      "Action" : "elasticache:*",
      "Effect" : "Allow",
      "Resource" : "*"
    }
  ]
}

Back To Top

I want a sticker! Where do I get one?

Send us an email at info@botfactory.io and we’ll ship you some stickers!

Back To Top