Skip to main content

Access Server Setup

If you would like to use the FireMon-managed Access Server, you can skip these instructions. Otherwise, to host the Access Server yourself, follow these instructions to install Access Server in your own AWS account. We recommend choosing an isolated account for security reasons.

  1. Download the access server source code from the Cloud Defense console and unzip it.
  2. Install Node.js 14+
  3. Install project dependencies: npm ci.
  4. Configure your AWS credentials to target the AWS account you wish to deploy the Access Server in.
  5. Follow either the CDK or CloudFormation instructions to deploy the Access Server.

You will need to provide the following shell variables to complete the next steps. They can be found in the Cloud Defense console.

DisruptOpsEventBusArn='The AWS ARN of the Cloud Defense EventBridge Bus used to collect events and register your Access Server'
DisruptOpsClientId='The DisruptOps-generated ID used to identify your Cloud Defense account'

CDK​

To use AWS CDK to install the Access Server for the first time, run the following commands:

# Note: this only needs to be done the first time you use the CDK in a particular AWS account and region (https://docs.aws.amazon.com/cdk/v2/guide/bootstrapping.html)
npx cdk bootstrap

# Optional. Allows you to view the CloudFormation template for the stack that will be created in the next step.
npx cdk synth

npx cdk deploy --parameters DisruptOpsEventBusArn=$DisruptOpsEventBusArn --parameters DisruptOpsClientId=$DisruptOpsClientId

If updating the Access Server, simply run npx cdk deploy.

CloudFormation​

If you prefer to use CloudFormation without CDK to install or update the Access Server, follow these steps:

  1. Generate a CloudFormation template from the CDK code:
# Required. The name of the bucket to store assets.
BSS_FILE_ASSET_BUCKET_NAME="..."
# Optional. BSS_FILE_ASSET_PREFIX is the path within the S3 bucket to store assets and should end with a forward-slash (/)
BSS_FILE_ASSET_PREFIX="..."
CDK_DEPLOY=false npx cdk synth > AccessServer.yml
  1. Upload the Access Server code to S3:
npx cdk-assets publish -p cdk.out/AccessServer.assets.json
  1. Create your CloudFormation stack using the AccessServer.yml template generated in Step 1. You can do so via the AWS console or CLI:
aws cloudformation create-stack --stack-name AccessServer \
--template-body file:///"$PWD"/AccessServer.yml \
--capabilities CAPABILITY_IAM \
--parameters \
ParameterKey=DisruptOpsEventBusArn,ParameterValue="$DisruptOpsEventBusArn"
ParameterKey=DisruptOpsClientId,ParameterValue="$DisruptOpsClientId"

If updating the Access Server, replace create-stack with update-stack.

External Identity Provider​

You also have the option of adding an extra layer of authentication to Access Server with an OAuth 2.0 or OIDC compatible identity provider (IdP) of your choice (e.g. Okta, Auth0, Google, etc.). When configured, users will be required to authenticate with the IdP after their request is approved but prior to receiving access credentials from the Access Server.

To set it up, provide the following additional CloudFormation parameters when deploying the Access Server via CDK or CloudFormation:

  • OAuth2RedirectUrl: The URL of your identity provider's OAuth 2.0 authorization endpoint. Include any required query parameters in the URL, such as client_id. However, you can omit redirect_uri and response_type. The Access Server will set redirect_uri with its own URL. You will likely need to add this URL to your IdP's list of trusted redirect URIs. It can be found in the Cloud Defense console. response_type will be set to code, since Access Server uses Authorization Code Flow. Access Server does not use the access token returned by a successful authentication, so scope can be set to the minimum scope allowed by your IdP. For example, https://YOUR-DOMAIN.okta.com/oauth2/default/v1/authorize?client_id=YOUR-CLIENT-ID&scope=openid
  • OAuth2TokenExchangeUrl: The URL of your identity provider's OAuth 2.0 token endpoint. This should not include any query parameters. For example: https://YOUR-DOMAIN.okta.com/oauth2/default/v1/token
  • OAuth2ClientSecret: The OAuth 2.0 client secret provided by your identity provider.

Putting it all together, the last command of the CDK step would change to become like:

npx cdk deploy \
--parameters DisruptOpsEventBusArn=$DisruptOpsEventBusArn \
--parameters DisruptOpsClientId=$DisruptOpsClientId \
--parameters OAuth2RedirectUrl="https://YOUR-DOMAIN.okta.com/oauth2/default/v1/authorize?client_id=YOUR-CLIENT-ID&scope=openid" \
--parameters OAuth2TokenExchangeUrl="https://YOUR-DOMAIN.okta.com/oauth2/default/v1/token" \
--parameters OAuth2ClientSecret="super-secretive-secret"

Frequently Asked Questions​

What is the AllowedRoleArns parameter...?​

...and why is it set to arn:aws:iam::*:role/access-server/*?

The AllowedRoleArns parameter is a comma-delimited list of ARNs of IAM roles that the Access Server is allowed to assume. This parameter is optional if all the roles to assume are in the same AWS account as the Access Server. However, AWS IAM requires that the Server's role has permission to assume roles in external AWS accounts.

Having an AllowedRoleArns value of arn:aws:iam::*:role/access-server/* allows the Access Server to attempt to assume a role in any account that starts with /access-server/. We say attempt because it is the target role's trust policy that ultimately determines who or what is allowed to assume it. So arn:aws:iam::*:role/access-server/* somewhat restricts what roles the server is allowed to try to assume, while allowing you to create roles in multiple target AWS accounts without needing to update the server's role with each target role's ARN, as long as the target role has a path of /access-server/.