Security Implications of Retaining a Stale DR Environment in Mendix Portal

0
I am seeking some inputs regarding the security implications of retaining the DR environment in its current stale state.We had multiple Mendix environments hosted on AWS. As part of the decommissioning activity, we removed the underlying AWS resources associated with these environments, including the VPC, EKS cluster, and worker nodes, and stopped the respective environments through the Mendix Portal.However, one DR environment remains in a stale state in the Mendix Portal, with the Gateway Agent disconnected. We do not intend to delete this environment, as we would like to retain its environment record and associated build/package information for future reference.Considering this situation, could you please confirm the following?Security impact on other environments: Can retaining this stale DR environment in the Mendix Portal create any security concerns or vulnerabilities for the other environments within the same Mendix Portal project that have been stopped?Cross-environment impact: Is there any possibility that the stale environment could affect the security, configuration, or operation of other environments in the same project, even though its underlying AWS infrastructure has been decommissioned?Residual security risks: Since the underlying AWS resources have been removed and the environment is not consuming a Mendix license, are there any remaining security risks associated with retaining the environment in its current state?Recommended action: Can we safely retain the environment in its stale state without deleting it, or would you recommend any additional steps to mitigate potential security concerns?I would appreciate the inputs on whether retaining this stale environment poses any security risk to the other stopped environments in the same project.Thank you for your support.
asked
1 answers
1


Hi Tushar,


Based on your description, retaining the stale environment record in Mendix Portal should not, by itself, create a security vulnerability in your other environments, provided the underlying AWS resources have been completely decommissioned.


I would distinguish between the environment's metadata in Mendix Portal and the infrastructure that previously hosted the application.


1. Impact on other environments


If the DR environment's VPC, EKS cluster, worker nodes, and associated resources have been removed, the stale Portal record does not mean the application is still running.

The other environments should remain independent, provided they do not share any remaining infrastructure, credentials, or resources with the decommissioned environment.


2. Cross-environment security risks


The main concern is not the stale record itself, but any resources that might have been left behind. I would verify the following:

  • AWS resources: Confirm that no associated load balancers, storage volumes, databases, snapshots, or other resources remain accessible.
  • Credentials and secrets: Review any IAM roles, access keys, service accounts, and secrets that were specific to the old environment. Revoke credentials that are no longer required.
  • Network access: Verify that security groups, firewall rules, and network routes do not retain unnecessary access.
  • Shared infrastructure: Confirm that the decommissioned environment did not use shared resources or credentials that are still active in other environments.

These checks help establish that the infrastructure has actually been decommissioned, rather than simply becoming unreachable.


3. Does the disconnected Gateway Agent create additional risk?


A disconnected Gateway Agent means Mendix Portal cannot currently communicate with that environment to perform normal management operations. It does not, by itself, indicate a security vulnerability.


Mendix documents that an orphaned environment can be force-deleted through the Deploy API when its Agent is disconnected. However, since you want to retain the environment record and deployment history, I would not recommend deleting it solely to resolve the stale status.


4. Recommended approach


Given that your requirement is to retain the environment and its associated build/package information:

  1. Keep the stale environment record for now.
  2. Verify that all associated AWS infrastructure and environment-specific credentials have been removed or revoked.
  3. Raise a Mendix Support ticket explaining that the DR infrastructure has been decommissioned, the Gateway Agent is disconnected, and you want to retain the environment metadata and deployment history.
  4. Ask Support to confirm whether the stale environment can remain safely in Portal and whether any cleanup is required.


My conclusion: If the underlying infrastructure has genuinely been removed and no shared credentials or resources remain exposed, retaining the stale Portal record should not, on its own, affect the security or operation of your other environments. I would still ask Mendix Support to confirm the supported cleanup options for your specific Private Cloud configuration.


Hope this helps.

answered