Software Security Features on Enterprise Serverless Slack Apps Enabled by Nimbella Commander
We have received a lot of questions from several of our users on the security features of Nimbella Commander. Commander enables Slack developers/users to write serverless functions as slash commands that can be executed within Slack. But just how safe are the functions once they’re created? How do Slack users make sure their API keys can’t be stolen if they’re used in a function? Can I restrict who has access to my functions? I wanted to be able to provide deep technical explanations, so I contacted the architect of Commander, Eric Swildens to answer these questions
1) Jamie: When I write and store my code in the editor provided by Commander, where is it running? What is being done to make sure that stored code is secure?
Eric: The code is hosted on the Nimbella platform which creates a unique namespace on the underlying platform for every Slack application. When a developer is using the Nimbella platform, the code in each namespace is isolated from the code in every other namespace. Code is stored associated with a specific namespace and when code is run, the code is run in an isolation Docker container. This prevents the running code from accessing the memory, networking, or any other resources of any other running function code. Only one function is run at a time in a given Docker container. When a function is done running, the container is cleaned up if other functions will be run in the container. If the same function can run in the container again, the container can be re-used but it can only be re-used by the same function. So your code is secured both at rest and at runtime.
2) Jamie: We run commands that access our resources on AWS, DigitalOcean, Google Cloud and other cloud services. How are my access keys to these services kept secure?
Eric: With Commander, you can store API keys and passwords as “secrets”. A user uses the Commander “secret creator” to encrypt values. The secret creator itself is a web interface and doesn’t keep any logs so nothing is retained in the history of the browser session. When a value is encrypted using the secret creator, it is encrypted internally using multiple 256-bit encryption keys. One of the internal keys is specific to the app that the secret is encrypted for. If an encrypted key did ever manage to leak from one app to another (which should never happen) the key in one app will not be able to decrypt the other app’s encrypted values.
Commander stores the encrypted key/value in a database. The unencrypted value is never stored in plain text or decrypted form.
When Commander calls a function to execute it, the key is decrypted as part of the command function invocation during runtime.
The multiple secret keys and encryption methods are internal to Commander. The encryption keys and encryption methods themselves are not available to external developers.
3) Jamie: Can I control who runs my code and who can edit my code?
Eric: Yes. There are 3 personas supported by Commander: Administrators, Coders, and Runners. They can also authorize who can code and who can run. They can install the commands and give access rights to different individuals. Coders can edit and run the code. Runners can only run the code.
Administrators can also create groups and assign these rights to a group of users.
4) Jamie: Who manages the user identity within Commander? Can someone else pretend to be another user?
Eric: Commander leverages identity by accepting the identity of the messaging system being used. In Slack, a user has authenticated through their Slack identity. Commander allows you to use that identity for access control. No separate identity is needed.
When Commander receives a request from Slack (when a slash command is run), it first authenticates that the request came from Slack. Slack has a method to verify a request comes from Slack itself using signatures and access tokens. Commander checks the signature/access tokens of the request to make sure the request is coming from Slack itself before doing anything.
When Slack sends a request, it also sends the user-identity associated with the request. This is how Commander validates a user running a Commander command.
5) Jamie: Can I see who ran the commands in case there is a problem?
Eric: Commander has a command for viewing audit logs per application, per command and per user. Only the users that I have access rights to run the specific commands can view the user logs. Administrators can view all logs.
If you wish to add Commander to your Slack account, then click on this link to get started!
- Nimbella joins DigitalOcean
- No infrastructure, just code. Learn the simplicity of serverless
- How to Migrate from Containers to Nimbella Serverless Architecture
- Kubernetes in simple words: explained by Eric Swildens
- How to optimize Kubernetes costs with Nimbella
- Step by step guide on how to port from AWS to Nimbella
- How to build and improve your serverless APIs
- Simplifying Kubernetes For Developers
- FaaS Wars Season 2 - Step By Step Instructions
- What is Nimbella and what does it offer?
- Results and Feedback of FaaS Wars - May the FaaS Be with You!
- 28 Serverless Gurus and experts One Must Follow in 2021
- The Faas Wars Alert!
- CI/CD pipeline with GitHub Actions
- How to deploy Node.js functions on Nimbella
- Kick-Start Your Serverless Journey
- AWS re:Invent Serverless Highlights
- Opportunities in the Wake of the AWS Juggernaut
- FaaS Wars: Serverless & Virtual Robot Competition
- #DeveloperIPL Online Hackathon Results & Feedback on Nimbella's Integration for Postman
- How to connect to the 3rd party database such as MySQL at Nimbella (example in Java)
- What can you do with the Nimbella Workbench?
- Deploy your Shopify Storefront to Nimbella
- Not All Serverless Platforms Are Created Equal
- Nimbella + Netlify: Uplevel Your Development Speed
- How we learned to Jamstack, Our Caputron story | Nimbella.com®
- Commander for Microsoft Teams - Your Custom Bot that runs on your Command!
- How to Build a Stateful Cloud App on Nimbella vs. AWS
- Starter Kit and Resources to Build a Serverless Cloud Application
- How to Build Serverless Slack Apps and Commands
- How to Set up your Serverless Environment and Get Started in Less than 2 Minutes!
- How to Quickly Deploy Stateful Serverless Apps with Nimbella?
- What is Serverless Computing? 3 reasons to start now
- How to Build a Serverless Slack App in Minutes.
- How to Manage your Netlify Website from Slack?
- How to Build a Serverless Slack Command in minutes
- How to Build a Stateful Serverless Cloud Web Application?
- How to Create an Optical Character Recognition (OCR) Application?
- Development at the Speed of Innovation – Nimbella, the Serverless Cloud
- Software Security Features on Enterprise Serverless Slack Apps Enabled by Nimbella Commander
- Coronathon India’s first demo day has 18 projects to help fight COVID-19
- See the time in different cities on Slack with Nimbella Commander
- Greet your friends in their native language in Slack with Nimbella Commander
- How to Fetch your Digital Ocean Billing Info on Slack?
- How to Stay Updated with Coronavirus Statistics on Slack?
- How to Fetch your AWS Billing Info on Slack?
- Get your Datadog billing info in Slack with Nimbella Commander
- Serverless Slack Apps and Slash Commands
- How to use Slack Effectively with Nimbella Commander?
- How to Create a multi-user Chatroom Hosted on Serverless Cloud?
- Using Docker actions, running Golang, and other fun things with OpenWhisk
- The duality between serverless functions and APIs
- Serverless HTTP handlers with OpenWhisk
- Serverless functions in your favorite language with OpenWhisk
- Run Swiftly: precompiled Swift actions
- Performance debugging for serverless functions using the Cloud Shell
- Locally debugging OpenWhisk actions
- Composing functions into applications
- A Serverless Composition of Functions
- The Serverless Contract
- The dawn of the Cloud Computer
- Security and Serverless Functions