Documentation for the Admin view of Shuffle. Best used by administrators.
With version 0.8.0, Shuffle was released with an Admin panel. This gives access to configure an organization, and will over time get more features. With the latest release, Shuffle introduced cloud syncronization, which gives access to certain cloud features on-premises.
Keep in mind that everything in this document is PER ORGANIZATION. This is paramount to remember, as all features should be connected to a user within a specific organization.
The organization overview gives access to a few things:
The point of this view is to get access to new features more easily. It can tell you about new updates, features and more that we have in store. The view is slightly different from the cloud version to the on-premises version. Here's how:
Cloud syncronization is a feature used to get more capabilities on-premises that otherwise wouldn't be possible. These range from scalability to collaboration and accessibility. The goal is to give access to features that otherwise are impossible to get otherwise. See Hybrid Features for more info.
Want to try it out? Send us an email
There are many features that make Shuffle more usable. These are mainly related to accessibility, scalability and collaboration - in that order. For the initial release (v0.8) of Shuffle, we've decided to focus entirely on accessibility. Every feature comes with some of the same basic features, so that you know what you're getting into.
These basic features are
These are the categories they fit into 1. Accessibility - Makes Shuffle easier to use. We make every open source function open source, but some are hard or impossible to make easy for a user to have.
You can see most of our currently planned features on https://shuffler.io/pricing.
Activation tells you whether the feature is active. It's indicated by the red or green mark next to the feature on the admin page.
Some features have limits. These are features such as SMS and email sending, schedule creation, cloud executions and more. Click each item to learn more.
The description exists to specify what exactly an action does. This will become more granular over time. Access it by clicking each feature.
There are three types of data sharing, where the initial launch of Shuffle uses none. You can see the usage as per the image in limits
The three levels we'll keep to are:
Our pricing tiers for Shuffle are currently split into three: Basic, Community and Pro. Basic is a support tier, and exists to make it possible for you to support us without having to use alternative means such as github sponsors. Everything we build out that can be priced is for us to further create a better offering for the open source community.
Whenever we add new features that can help Shuffle work better by leveraging cloud resources, you'll automatically get access to it if you're on that tier.
These are our tiers:
The basic tier is meant as a way for people to support Shuffle. It will give more perks over time, but to start of, it gives you and your team an onboarding meeting with Shuffle to get you kickstarted as well as some community support features.
Community is the tier where you may get core hybird features, as well as become a part of the community. The key starting features you'll get use of are the triggers and outbound features we've made: Schedules, Webhooks, User Input continuations and SMS / Email sending through Shuffle. We'll soon expand this to doing cloud executions with Shuffle.
Pro is the full package. It is meant for those of you who want everything from support to auditlogging, datacenter choices, compliance overviews, data retention control, reporting, and more. This package is currently not available as
Get in touch at email@example.com if you want something more specific.
Only available onprem (20.11.2020)
User management is all about adding, listing, deleting and controlling users in general. Users are a part of a specific organization, and are created by organization admins. To add users you need the "admin" role.
Click the "ADD USER" button, and you'll get a popup. Type in their username (open source) or email (cloud), and you'll create an invite for them. Cloud will not allow an admin to set a password to share, but rather send them an email. This will also be a part of the hybrid offering later.
Click the "Role" dropdown and choose one. Defaults are Admin and User, but we'll add granular access for this now. To repeat, here's the current roles:
A user in Shuffle can't be deleted, but deactivated. This is to keep all references available for when audits eventually require them. Click "Edit user", then "Deactivate". This prevents the user from being used. A deactivated user can be reactivated.
App authentication is a way for Shuffle to keep track of what credentials you have for an app in a specific organization. It shows you information the most important information, and gives you access to modify or easily delete them. Authentication is specified at the app level, and applies to ALL functions of the the app, unless specified otherwise. Authentication is created during workflow editing.
These are NOT editable outside of deletion as of november 2020, but we may add the possibility of changing without showing the previous value.
The fields of authentication
Authentication is and should be defined the first time you use an app. We'll use the example of TheHive, which takes the fields "apikey" and "url". Start by creating a workflow, before dragging in the app "TheHive".
Once it's in, click the node, and you'll see a view like this. We've outlined three places that indicate this app requires authentication. All of these are also clickable.
By clicking either of these, a popup window will show. In this one, type in a DESCRIPTIVE name (to remember), before passing credentials. PS: Never use localhost in an URL. Everything runs in a container, which has its own IP. Always use the system's IP/domain within the URL.
By clicking "submit", the authentication is now saved for your organization. This removes clutter in the UI, by having less required fields, and is also reusable. You can now make multiple nodes that use the same authentication.
Last, but not least, this can now be controlled on an organizational level.
The fields are specified by the app creator. This short section outlines how to create authentication as a creator. More on this in the apps section. An example is TheHive, which takes a URL and an API-key. These fields have to be specified as seen below.
Outer level: authentication Inner level: parameters
These parameters are specified exactly as a parameter within an action. The function's code needs to reflect it as well, as can be seen with this python function, taking an apikey and URL.
Environments are a core part of Shuffle's open source build. Think of it as physical location where you want an agent of Shuffle running (Orborus). Orborus is the tool that keeps your workflow running. But Orborus needs to know what jobs to run. Afterall, we'd like it you to be able to run parts of a workflow in the cloud and parts of it in all your different datacenters.
The default environment is called "Shuffle". You can add as many as you want, but you'll only get access to "cloud" environments through cloud syncronization.
If you would like to run Orborus towards a different environment, you'll have to specify the environment variables "ENVIRONMENT_NAME", "ORG_ID" and "BASE_URL".
Here's an example, where the environment's name is "Hallo" and backend is at http://192.168.3.6:3001
docker run -d \ --volume /var/run/docker.sock:/var/run/docker.soc \ -e ORG_ID="Hallo" \ -e ENVIRONMENT_NAME="Hallo" \ -e BASE_URL=http://192.168.3.6:3001 \ ghcr.io/frikky/shuffle-orborus:0.8.0
This view is an overview of schedules created within workflows. You can stop them from here, but you'll have to visit the workflow itself to edit the schedule.
This view is an overview of files created within workflows. These are a way of looking for a specific file and downloading them (November 2020). Files are created from Actions in Workflows, and are restricted per Organization.
TBD Granular access (role based) rights is an upcoming feature for organizations and users. It will allow you to control what specifically an account has access to.
TBD App categories are a way to keep an overview of your current apps and their use-cases. SIEM is SIEM. EDR is EDR. Ticketing system is Ticketing system. VMS is VMS. That's what this is for. A way to swap your workflows in an easy fashion.