Gateway Enrollment with Portal without OTK
This experimental feature is a first step in supporting the ability to enroll gateways with the portal without requiring OTK to be installed. This feature is intended to allow customers to test out this configuration and provide Broadcom with feedback. It is NOT intended for use in a production environment.
With this feature, gateways can be enrolled with the Portal without having to install and configure the OTK. In this configuration, the API Key data normally stored in the OTK DB, will instead be stored on each gateway node in local in-memory cache. This allows greatly improved sync times between the gateways and portal however it is intended for scenarios where there will be less than 100K overall API keys. Future versions will provide similar functionality using external cache solutions and/or external storage options to support much larger numbers of API keys.
To get access to the artifacts to test this experimental feature, please contact Product Management at gregory.thompson@broadcom.com
Pre-Requisites
Gateway versions: 11.0+
Portal version: 5.2.3
Limitations
Only supports Automatic deployment mode for API Key deployments.
Steps
-
set the FEATURE_FLAG_DECOUPLE_OTK feature flag setting to true
-
ensure your Gateway has the PortalBootstrapAssertion installed which removed the OTK requirement checks (this file is included in the shared folder provided by Product Management)
-
to install the assertion, follow these steps:
-
deploy gateway without OTK installed
-
transfer file to gateway: scp PortalBootstrapAssertion-11.1.00.16392.aar root@<GATEWAY_HOST>:~
-
ssh to gateway and backup old PortalBootstrapAssertion: mv /opt/SecureSpan/Gateway/runtime/modules/assertions/PortalBootstrapAssertion* /opt/SecureSpan/Gateway/runtime/modules/assertions/PortalBootstrapAssertion.aar-bkup
-
move new PortalBootstrapAssertion-11.1.00.16392.aar to assertions directory: mv PortalBootstrapAssertion-11.1.00.16392.aar /opt/SecureSpan/Gateway/runtime/modules/assertions/
-
restart Gateway: service ssg restart
-
create a new Proxy using PAPI setting the apiKeyStore property to LOCAL_STORAGE:
- this will create the Proxy with its API Key deployment type as AUTOMATIC
- you can set the API Key deployment type to ON_DEMAND but you must always have one Gateway node connected to the Portal ensuring that there is a record of the Proxy's current API Key deployment state so that new nodes can have the same state deployed to them
-
enroll the Gateway using the enrollment URL from step #3
-
install the Gateway bundle Local API Key Storage Bundle-0.0.1 in the Portal by uploading the 3 bundle files in the Manager->Gateway Bundles menu (files provide in shared folder by Product Management)
-
if you have the Products feature enabled and its RL&Q bundle already installed
-
deploy the Local API Key Storage Bundle to your Proxy
-
deploy the Products RL&Q bundle to your Proxy
-
revert the following policies to the previous revision using Policy Manager:
-
::l7.apim.system::Rate & Quota Enforcement Policy Template::2.0
-
::l7.apim.system::App Product Rate & Quota Mapping Lookup::2.0.
-
re-trigger the bulk deployment for all the Proxies nodes by toggling the portal.deployer.enabled CWP from true → false → true using Policy Manager
-
if you don't have the Products feature enabled
-
deploy the Products RL&Q bundle to your Proxy
-
deploy the Local API Key Storage Bundle to your Proxy
-
understand these APIs:
-
GET deployments/0.1/proxies/{proxyUuid}/nodes to fetch all the nodes in the Proxy that are connected to the Portal
-
GET deployments/0.1/proxies/{proxyUuid}/nodes/{nodeUuid}} to fetch an individual nodes API Key deployments
-
POST deployments/internal/proxies/{proxyUuid}/nodes/{proxyNodeUuid}/api-keys to trigger a bulk deployment to the node.
Notes
------------------------------
Greg Thompson
Layer7 Product Management
------------------------------