Cloud Storage Security Help Docs
Release Notes
  • Introduction
  • Getting Started
    • How to Subscribe
      • Pay-As-You-Go (PAYG)
      • Bring Your Own License/GovCloud (BYOL)
      • AWS Transfer Family
    • How to Deploy
      • Steps to Deploy
      • Advanced Deployment Considerations
      • AWS Transfer Family
    • How to Configure
  • Console Overview
    • Dashboard
    • Malware Scanning
      • AWS
        • Buckets
        • Amazon EBS Volumes
        • Amazon EFS Volumes
        • Amazon FSx Volumes
        • WorkDocs Connections
      • Azure
        • Blob Containers
      • GCP
        • GCP Buckets
    • See What's Infected
      • Findings
      • Malware History
      • Results
    • Schedules
    • Monitoring
      • Error Logs
      • Bucket Settings
      • Deployment
      • Jobs
      • Notifications
      • Storage Assessment
      • Usage
    • Configuration
      • Classification Rule Sets
      • Classification Custom Rules
      • Scan Settings
      • Console Settings
      • AWS Integrations
      • Job Networking
      • API Agent Settings
      • Proactive Notifications
      • License Management
      • Event Agent Settings
    • Access Management
      • Manage Users
      • Manage Accounts
        • Linking an AWS Account
        • Linking an Azure Account
        • Linking a GCP Account
      • Manage Groups
    • Support
      • Getting Started
      • Stay Connected
      • Contact Us
      • Documentation
  • Product Updates
  • How It Works
    • Scanning Overview
      • Event Driven Scanning for New Files
      • Retro Scanning for Pre-Existing Files
      • API Driven Scanning
    • Architecture Overview
    • Deployment Details
    • Sizing Discussion
    • Integrations
      • AWS Security Hub
      • AWS CloudTrail Lake
      • AWS Transfer Family
      • Amazon GuardDuty
      • Amazon Bedrock
    • Demo Videos
    • Scanning APIs
    • SSO Integrations
      • Entra ID SSO Integration
      • Okta SSO Integration
  • Frequently Asked Questions
    • Getting Started
    • Product Functionality
    • Architecture Related
    • Supported File Types
  • Troubleshooting
    • CloudFormation Stack failures
    • Cross-Region Scanning on with private network
    • API Scanning: Could not connect to SSL/TLS (v7)
    • Password not received after deployment
    • Conflicted buckets
    • Modifying scaling info post-deployment
    • Objects show unscannable with access denied
    • Remote account objects not scanning
    • My scanning agents keep starting up and immediately shutting down
    • I cannot access the management console
    • Linked Account Out of Date
    • Rebooting the Management Console
    • Error when upgrading to the latest major version
    • I Cannot Create/Delete an API Agent
  • Release Notes
    • Latest (v8)
    • v7
    • v6 and older
  • Contact Us & Support
  • Data Processing Agreement
  • Privacy Policy
Powered by GitBook
On this page
  • Background
  • The Fix
  • Possible reasons the URL is not working
  • Finding your public IP address:¶
  1. Troubleshooting

I cannot access the management console

If you are having trouble accessing the management console the below information may be helpful.

PreviousMy scanning agents keep starting up and immediately shutting downNextLinked Account Out of Date

Last updated 2 years ago

Background

It may occur that you are unable to access the management console UI. This could occur right after installation, after a reboot (from an update or another reason) or after you have changed the subdomain name. The first two scenarios typically turn out to be Subnet issues and the last is typically a DNS issue (if it is temporary).

During deployment you are asked to specify a VPC and 2 Subnets (preferably in different AZs) for the Console to run in. If you want to access the console publicly then the subnets must provide public access. What we have seen with numerous customers is that they will pick 2 subnets, one happens to be public and one happens to be private. Inevitably during the initial boot or after a reboot the console spins up on the private subnet and then can no longer be accessed from the URL or public IP. Ensure the subnets you choose are both public so no matter which the console spins up in, you'll be able to get to it.

Neither the console nor the scanning agents require a public IP, however:

  • They must have outbound to the internet routes (to pull ECR images).

  • They must if you want to access the application from the URL.

  • If you have a VPN or Direct Connect you can access from the private IP and forget the public IP.

You can leverage an Internet Gateway and/or VPC Endpoints (for those services available) to access what is needed without public outbound access. Checkout the for more details on public and internal routing.

There are times, typically right after the subdomain changes, that you cannot access the application from the new URL. This is typically a DNS issue and you just have to wait for DNS to catch up in your area. If this issue persists longer than you expect, try to access the console via the public IP assigned to it which can be identified in the AWS Console. If neither work, then explore the subnet issue described above.

The Fix

There is an easy way to fix this. Run a Stack Update and select two new subnets. Identify before hand which are public or which will provide the access mechanism you'd like to use. For the stack update you will use the existing template and make no other changes but the subnets. When you are able to get back into the console, you can double check your VPC and Subnets on the page.

  • If desired, you could create an entirely new VPC with Subnets designed to work how you expect and run the console off of those.

  • Allow DNS enough time to distribute to all locations.

  • Check your Security Groups. One user's work/home IP changed and the Security Group was set to only allow the previous IP to access.

The vast majority of the time, it will be a VPC or DNS issue as described above. If you do not believe either of those to be the case, then one other trouble shooting step you could take is go to the ECS service in the AWS Management Console to ensure the console task is running. If it is you can drill down into the task itself to find the public and private IPs and attempt to access the console directly from those. If you can, then you know the console is up and running properly and the issue lies in the registration with Route53. Please if this is the issue.

Possible reasons the URL is not working

We have seen a couple of scenarios where there is a public IP, but DNS fails to come back and allow you to leverage the URL in the CloudFormation outputs.

  • VPCs with proxies/firewalls/etc steering traffic and enforcing allowed URLs

    • add cloudstoragesecapp.com to the allowed list

  • Blocking outbound HTTPS calls which are used to register with Route53

    • ensure HTTP calls can be made outbound

  • No outbound internet access

As suggested above, you can go into the Console Task itself and find the public and private IPs and attempt to access with those. If you can, then one of the items listed above could be in play to affect the URL access. If you choose to access the application privately, work out a method that gives you consistent access to the Console task even after reboot.

Once in the ECS Management Portal, find the Cloud Storage Security cluster.

Find and click into the Console service.

Select the Tasks tab and click into the Task.

Locate the public IP on the Task details screen.

Now try to access the console with the IP found. If you can access it directly, then you know the application is up and running properly and you are facing a DNS issue.

Finding your public IP address:

Login to the and navigate to the Elastic Container Service area.

Deployment Details page
Console Settings
contact us
¶
AWS Console