MuleSoft's Anypoint Runtime Fabric is a container service that brings cloud benefits to "on-premise" Mule app deployments. However, if you are familiar with how to secure CloudHub applications, you'll quickly learn that the way to secure Runtime Fabric applications is quite different.
By attending this Meetup, you'll learn the nuances of securing your Runtime Fabric applications. Big Compass' MuleSoft Practice Manager, Brian Statkevicus, and one of Big Compass' MuleSoft Consultants, Connor Fitzgerald, will cover the following topics:
* A brief introduction to Anypoint Runtime Fabric (RTF)
* Secure your RTF deployment
* Secure your APIs from a variety of threats, both external and internal
* Secure your at-rest configuration properties
* Secure your in-flight data through Tokenization
After this Meetup, you'll know what to expect when you develop your RTF security strategy.
SQL Database Design For Developers at php[tek] 2024
Chicago rtf meetup august 17 2021
1. August 17, 2021
Chicago (Virtual) MuleSoft Meetup Group
Deep Dive into Anypoint Runtime Fabric Security
2. Forward-looking statements
2
"Safe harbor" statement under the Private Securities Litigation Reform Act of 1995: This presentation contains forward-looking statements about the company's financial and
operating results, which may include expected GAAP and non-GAAP financial and other operating and non-operating results, including revenue, net income, diluted earnings
per share, operating cash flow growth, operating margin improvement, expected revenue growth, expected current remaining performance obligation growth, expected tax
rates, stock-based compensation expenses, amortization of purchased intangibles, shares outstanding, market growth, environmental, social and governance goals and
expected capital allocation, including mergers and acquisitions, capital expenditures and other investments. The achievement or success of the matters covered by such
forward-looking statements involves risks, uncertainties and assumptions. If any such risks or uncertainties materialize or if any of the assumptions prove incorrect, the
company’s results could differ materially from the results expressed or implied by the forward-looking statements it makes.
The risks and uncertainties referred to above include -- but are not limited to -- risks associated with the effect of general economic and market conditions; the impact of
geopolitical events, natural disasters and actual or threatened public health emergencies, such as the ongoing Coronavirus pandemic; the impact of foreign currency exchange
rate and interest rate fluctuations on our results; our business strategy and our plan to build our business, including our strategy to be the leading provider of enterprise cloud
computing applications and platforms; the pace of change and innovation in enterprise cloud computing services; the seasonal nature of our sales cycles; the competitive
nature of the market in which we participate; our international expansion strategy; the demands on our personnel and infrastructure resulting from significant growth in our
customer base and operations, including as a result of acquisitions; our service performance and security, including the resources and costs required to avoid unanticipated
downtime and prevent, detect and remediate potential security breaches; the expenses associated with our data centers and third-party infrastructure providers; additional data
center capacity; real estate and office facilities space; our operating results and cash flows; new services and product features, including any efforts to expand our services
beyond the CRM market; our strategy of acquiring or making investments in complementary businesses, joint ventures, services, technologies and intellectual property rights;
the performance and fair value of our investments in complementary businesses through our strategic investment portfolio; our ability to realize the benefits from strategic
partnerships, joint ventures and investments; the impact of future gains or losses from our strategic investment portfolio, including gains or losses from overall market
conditions that may affect the publicly traded companies within our strategic investment portfolio; our ability to execute our business plans; our ability to successfully integrate
acquired businesses and technologies; our ability to continue to grow unearned revenue and remaining performance obligation; our ability to protect our intellectual property
rights; our ability to develop our brands; our reliance on third-party hardware, software and platform providers; our dependency on the development and maintenance of the
infrastructure of the Internet; the effect of evolving domestic and foreign government regulations, including those related to the provision of services on the Internet, those
related to accessing the Internet, and those addressing data privacy, cross-border data transfers and import and export controls; the valuation of our deferred tax assets and
the release of related valuation allowances; the potential availability of additional tax assets in the future; the impact of new accounting pronouncements and tax laws;
uncertainties affecting our ability to estimate our tax rate; uncertainties regarding our tax obligations in connection with potential jurisdictional transfers of intellectual property,
including the tax rate, the timing of the transfer and the value of such transferred intellectual property; the impact of expensing stock options and other equity awards; the
sufficiency of our capital resources; factors related to our outstanding debt, revolving credit facility and loan associated with 50 Fremont; compliance with our debt covenants
and lease obligations; current and potential litigation involving us; and the impact of climate change.
Further information on these and other factors that could affect the company’s financial results is included in the reports on Forms 10-K, 10-Q and 8-K and in other filings it
makes with the Securities and Exchange Commission from time to time. These documents are available on the SEC Filings section of the Investor Information section of the
company’s website at.
Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements, except as required by law.
4. Moving from On-Prem to Runtime Fabric
Achieving Top Notch Security in RTF
● How do we secure secrets?
● How do we leverage what is already available in MuleSoft to secure our precious data assets?
● What is the best way to go about encryption of properties at rest?
● When does tokenization come in? How is it different from encryption? What are the benefits of doing one
over the other?
● What other aspects of security do we have to consider when we deploy our API’s to Runtime Fabric?
● What are the risks involved if we do not employ certain techniques to secure our API’s?
● What is the most important thing we must do to achieve security in the Runtime Fabric environment?
4
7. Anypoint Runtime Fabric
VM
Mule
App
VM
Mule
App
Mule
App
Runtime Fabric components
Runtime Fabric appliance
Mule
App
network
Runtime Fabric
Mule
App
Mule
App
VM
Runtime Fabric orchestrates and automates the
deployment of Mule runtimes into containers in any
cloud or on-premises environment
Benefits
● Flexible deployment upon existing infrastructure or
managed K8s services
● Deploy consistently across any cloud or data center
● Run multiple runtime versions in the same Runtime
Fabric
● Scale horizontally and redeploy w/ zero-downtime
● Easily manage via the control plane hosted by
MuleSoft
Overview
8. Deploy and manage runtimes on AKS, EKS, or GKE
Runtime Fabric on AKS, EKS, and GKE
Extend control plane benefits to
runtimes on your AKS, EKS, or
GKE
● Customer gets the latest
management and monitoring
features of Anypoint Platform
Decouple Mule runtime services
from your own infrastructure
● Give your ops teams the power
to use their infrastructure how
they want
8
CUSTOMER’S NETWORK
Mule
App
Mule
App
Mule
App
Runtime Fabric services
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Mule
App
Runtime Plane
CONTROL
PLANE
Kubernetes-as-a-Service
Available now
GKE
9. Deploy and manage across any K8s service
Deploy across private
clouds
Open K8s access to
managed providers
Expanded K8s access
on managed providers
Across any K8s
service
EKS
AKS
GKE
● Deploy standalone cluster
within AWS, Azure, or on-
prem
● Use K8s and docker without
K8s expertise
● Install RTF services into
private K8s environment
● Open access for customers
with existing K8s expertise
● COMING SOON! Support
for OpenShift container
platform
● COMING SOON! Run Mule
and non-Mule workloads on
the same K8s environment
● Open support for any
managed service built on
K8s
● Deploy across any K8s
environment
11. Appliance vs EKS, AKS, & GKE
Runtime Fabric Appliance
VM
Mule
App
VM
Mule
App
Mule
App
Runtime Fabric components
Runtime Fabric appliance
Mule
App
network
Runtime Fabric appliance
Mule
App
Mule
App
VM
Managed by Customer
Managed within Anypoint Platform
Customers bring their own hardware and
networking, and install Runtime Fabric on top
of it.
● Self-contained appliance-model
● Customers maintain the infrastructure
● MuleSoft maintains the Kubernetes
stack, RTF services and Mule
deployments
12. Appliance vs EKS, AKS, & GKE
Runtime Fabric is delivered to customers
as a package of components that run on
top of an existing EKS, AKS, or GKE
environment.
Customers bring their own Kubernetes,
ingress controller, and external log
forwarding and install RTF within it.
Customers maintain the health of
Kubernetes, and MuleSoft maintains the
RTF services and Mule deployments.
Runtime Fabric on EKS / AKS / GKE
Node
Mule
App
Node
Mule
App
Mule
App
Runtime Fabric services
EKS or AKS
Mule
App
network
Runtime Fabric on EKS / AKS
Mule
App
Mule
App
Node
Managed by K8s specialist
Managed within Anypoint Platform
15. ● EKS / AKS / GKE are
highly available and
managed by cloud
provider.
● Managed worker nodes
simplify node scaling
and upgrades.
● More customizable to
your organization’s
environment.
● Choose your own
ingress controller and
log forwarding agents.
Lower Cost
Benefits of RTF on EKS / AKS / GKE
More Flexible
● EKS / AKS/ GKE
replaces the controller
nodes.
● Pricing for Kubernetes
services provided by
IaaS
Less Overhead
16. Key Changes
RTF on EKS/AKS/GKE RTF appliance
Support for deploying Mules and API Gateways Supported. Supported.
Kubernetes and Docker Customers bring their own K8S via
provisioning EKS or AKS or GKE
clusters. MuleSoft supplies Docker
images
Included.
Support for installing on any Linux distribution Supported. RHEL and CentOS only.
Support for node auto-scaling Supported using Azure, AWS, or
Google settings
Not supported.
Support for external log forwarding Customers bring their own external log
forwarder.
Included.
Support for internal load balancer Customers bring their own internal load
balancer (called “Ingress Controller”)
Included.
17. Key Changes (cont)
RTF on EKS/AKS/GKE RTF appliance
Support for Anypoint Security Edge Not supported. Supported.
Ops Center Not included. Customers can enable
similar monitoring and alerting from
Cloud console
Included.
Support for Persistence Gateway (new in v1.9.1 -
Apr 20, 2021 release). Permits data storage and
sharing across Mule application replicas and
restarts
Supported. Supported.
Tutorials on how to get started with RTF on EKS/AKS/GKE are here: https://developer.mulesoft.com/tutorials-and-howtos
18. Trivia Question #1
Which of the following DO self-managed Kubernetes RTF installations provide?
A. Internal load balancer
B. Resource and Infrastructure monitoring via Ops Center
C. Ability to deploy applications from Runtime Manager
D. Log forwarding agent
22. 22
Recommended Network Configuration
This is the default recommended configuration.
Note the following in this diagram:
● 3 controller nodes, 3 worker nodes. This
configuration enables fault tolerance if you
lose one controller node. Agents are deployed
to controller nodes.
● External load balancer forwards request to
available internal load balancer.
● Internal load balancer decrypts request and
sends request to available replica of the Mule
app
● All nodes are on the same subnet. This is the
recommended configuration for latency
reasons and networking simplicity.
23. 23
Network Security Best Practices
Based on this diagram:
● Ensure only IP addresses that are required
are open
● Ensure only ports that are required are
open
● Use an external balancer. This ensures
that Ingress communication is limited to a
trusted source (the external load balancer)
● You can deploy using a private and public
subnet model. Be aware if you set this
model up you will need to communicate
over low latency across subnets.
25. 25
● Uses multiple components to protect at multiple layers
● Generally viewed as a best practice
○ Each layer has a “backup” to counter any flaws or gaps in a particular layer
○ Usually superior to a single defense layer
● Drawbacks:
○ Can be costly depending on the components used
○ Can negatively impact performance
Layered Security
26. 26
● Protects against “brute force” and other simple attacks
● Gateway Security measures include
○ OAuth 2.0
○ Rate limiting
○ IP whitelisting/blacklisting
○ Client ID/Secret
○ JWT
○ SAML
First layer - API Gateway
27. 27
● WAF (Web Application Firewall) and RASP
(Runtime Application Self Protection) protect
against some of the OWASP “Top 10” attacks
https://owasp.org/www-project-top-ten/
● When combined with API Gateway, can defend
against:
○ SQL Injection
○ XML Threat
○ Cross site scripting
○ DoS
Second layer - WAF/RASP
28. 28
● Implements “Zero-Trust” Security
● Last line of defense that models API behavior
● Can detect deviations from normal behavior
● Protects against:
○ Stolen tokens and credentials
○ Insider threats
○ Authenticated access
Third layer - ML/AI
29. 29
● Used to apply “Edge” Security policies
○ DoS
○ IP Whitelist
○ HTTP Limits (size and headers only)
○ WAF
● Applies to all applications in RTF
● Can still configure individual application policies
using API Manager
● Does not provide ML/AI layer of protection
○ A custom policy plus a 3rd party solution
will enable this layer of security
● NOT supported on EKS/AKS/GKE
deployments
Anypoint Security
31. The Challenge
● Enterprise Information Systems (EISs) need credentials
○ Often use “service accounts” for automated integration solutions
○ These credentials may be subject to routine maintenance (i.e. change every 90 days)
● Other sensitive information may need to be secured
○ URLs
○ IP Addresses
● Storing these credentials in plain text is a sure-fire way to fail a security audit!
32. Step #1 - Secure Configuration Properties
Secure Configuration Properties
○ Uses https://docs.mulesoft.com/downloads/mule-runtime/4.2/secure-properties-tool.jar and your
favorite command line tool
○ Also requires Mule Secure Configuration Property Extension
○ Can encrypt individual properties, all properties, or the entire file content
○ Can use .yaml or .properties files
○ Requires key as a command line parameter
○ Preface your properties with “secure::”
Note: Another option to encrypt properties is to use the “Premium Security
Connector” at this site: http://security-update-site-1.4.s3.amazonaws.com/ .
However, this solution is not in ‘official’ Mule 4.3 documentation AND can only
be used with .properties files. We will not cover this solution in this presentation.
33. Step #2 - Safely Hidden Application Properties
Safely Hidden Application Properties
○ Not the same as CloudHub “Safely Hidden” Properties
■ Use mule-artifact.json for CloudHub “Safely Hidden” Properties
■ Consider injected properties
○ Use “rtfctl” as follows: sudo ./rtfctl apply secure-property --key <my_key> --value <my_value> -n <environment_id>
○ Note that you can still view the properties:
sudo ./rtfctl get secure-properties -n 92af6926-9a73-4858-9481-fe2a2668bd9b
KEY VALUE
decryptionKey <<value in plain text>>
34. Demo!
● What you will see:
○ Local connection testing with Secure Configuration Properties
○ Safely Hidden properties on RTF
○ Edge Security and API Manager Policies
● What you won’t see:
○ Deploying to RTF
35. Demo wrapup
● You saw:
○ How to locally encrypt property
○ How to test from Connector - and the pitfalls of doing so
○ Safely Hidden properties on CloudHub
○ Safely Hidden properties on RTF
○ Edge Security policy
○ API Manager policy
○ Custom policy for AI/ML solution
36. Trivia Question #2
What is the most secure way to ‘hide’ sensitive configuration properties?
A. Secure Configuration Properties
B. RTF Safely Hidden Properties
C. CloudHub Safely Hidden Properties
D. Continuous Development/Deployment injected properties
38. 38
● Used to protect sensitive information
● Format preserving
● Service must be deployed to RTF instance
● Reversible
● Vaultless
● Scalability
● Flexibility
● Format support
Tokenization
39. 39
● Can be applied to any RTF deployed proxy
● Replaces sensitive data in the payload with
tokens
● Configurable
○ Selector expression
○ Request or Response
○ Formats
Tokenization Policy
41. Demo!
● What you will see:
○ Tokenization and Detokenization Policies
● What you won’t see:
○ Tokenization service deployment
○ Token format configurations
42. Trivia Question #3
Which of the following is false?
A. The tokenization is reversible through a detokenization policy
B. The tokenization service does NOT maintain a vault or lookup
table
C. RTF installations include the tokenization service by default
D. Formatting is preserved after tokenization