GRAX Managed Deployments require a cross-account IAM role with the permissions to create and manage the GRAX Application's infrastructure in a dedicated AWS Cloud account. You can create this IAM role automatically with GRAX's IAM Quick Deploy or manually create the required IAM role.
External ID: A Unique ID generated by GRAX for this connection which is used when creating the IAM role's Trust Policy See this AWS documentation for details.
Role ARN: The Amazon Resource Name for the cross-account IAM role you are providing to GRAX.
Ensure you are logged into your dedicated AWS account on another tab and click the "IAM Role Quick Deploy" button. GRAX will create a CloudFormation stack for an IAM cross-account role with the required permissions.
Ensure you are logged into the target AWS account with an Admin level user or a user with access to create IAM cross-account roles.
Click the IAM role Quick Deploy button. GRAX will open AWS in a new tab and load our certified for the cross-account IAM role.
Deploy the stack by clicking "Create Stack" in the lower right corner. You can also preview the IAM role and associated policies by creating a change set prior to creating the stack.
After you create the stack or execute the change set, click on the Resources tab in the stack to view progress. After a few minutes the AssumeRole resource will have a status of CREATE_COMPLETE. You may need to refresh the page.
While our Quick Deploy process is highly recommended, your AWS Administrator can manually create the IAM role for GRAX if they choose to do so. The IAM role must have the following:
Trust Policy allowing sts:AssumeRole to GRAX AWS Account 999875163122.
A Trust Policy condition limiting to the External ID (copied from the Platform Connection referenced above) is highly recommended.
Permission to Create, List, and Delete all the necessary GRAX infrastructure.
GRAX Support cannot provide assistance with AWS IAM roles not created from our .
Our Platform Connections reviews GRAX Security practices and goes into more detail on best practices for this configuration.
Click on the link for grax-platform in the Physical ID column to open the newly created role.
Copy the ARN value from this page and paste it into the ARN role field in GRAX Platform.
Click Save in GRAX Platform.
The AdministratorAccess policy is the most straightforward way to accomplish this.
The GRAX Platform serves as a central hub for deploying, managing, and monitoring GRAX Applications and their underlying infrastructure across multiple clouds. Each GRAX "deployment" is a self-contained infrastructure stack entirely isolated from all others. This section will cover the following topics:
Logging in
Creating a Team
Connecting a cloud account
Deploying a GRAX Application
Accessing a GRAX Application
Deleting a GRAX Application
To log in to the GRAX Platform, navigate to and choose a Social Sign-on method or create a new account. You can use your Salesforce, Google, or Microsoft account to log in to avoid managing a separate set of credentials. Keep in mind that each Salesforce user in each independent Salesforce org is a separate user so logging in with your user from one org is different from logging in with your user from another org.
By default, all Platform users are on a "personal team." This team is created when you sign up and can be used just like any other including inviting other users to it. However, if you're part of a larger organization, you may want to create a new team with an appropriate name to manage your GRAX deployments. To create a new team, click on the "Teams" dropdown in the lower left-hand corner and then click "Create New Team" at the bottom of the list. Fill out the form with your team's name and click "Save."
Deploying a GRAX Application via Platform also deploys the underlying infrastructure to the target cloud environment. Accordingly, you must connect a cloud account to the GRAX Platform with the necessary privileges to create and maintain the and the required . This account must remain connected to the GRAX Platform throughout the lifetime of the deployment as GRAX manages updates, upkeep, and patching for the environment.
To connect a cloud account, click on the "Connections" option in the navigation menu and then select the "Connect" button for your provider of choice.
For AWS, reference the separate .
For Azure, reference the separate .
For Heroku, reference the separate .
To deploy a GRAX Application, click on the "Deployments" option in the navigation menu and then click the "New Deployment" button in the top right corner. Choose the deployment type that best suits your use case and cloud expertise. If you've selected a deployment type that requires a cloud account but such a connection does not exist, you will be prompted to connect your account. Once you have a valid connection, click "Create Deployment" to begin the deployment process.
By default, all teams are allowed to provision a single GRAX Trial deployment. The infrastructure resources for Trials are deployed to a GRAX-owned cloud account and are intended only for use as a trial run of the GRAX Application. All Trials are automatically deleted after 7 days, data included; GRAX Archive is not available during Trials to avoid data loss. If you deploy any other deployments, the Trial option will no longer appear for your team.
Regardless of deployment method or cloud account, deployment will take roughly 15 minutes.
Once the deployment is complete, the deployment will be listed as "Running" on the "Deployments" list. Click the "Open" button to launch the new application in another tab or "Details" to see infrastructure status and options for configuration. Once deployment is complete for each application, all configuration for that application's Backup, Archive, Restore, and other features will be done within the application itself. The deployed application is isolated from the GRAX Platform and all other GRAX applications.
GRAX manages the domain name and ingress configuration for each deployment. All deployments will be provisioned a unique domain name under *.secure.grax.io that is accessible via HTTPS. Domain names for GRAX apps can be customized upon request, but this requires DNS changes for whichever domain you would like to use. WAF and other security configurations can also be customized upon request (depending on availability).
If you no longer have any need for a GRAX Application, it can be deleted in the GRAX Platform via the "Danger Zone" on the "Details" page. After manually confirming the deployment name and team, submit the delete form to start the de-provisioning process. Once the deployment is de-provisioned, all data and resources associated with the deployment are destroyed and cannot be recovered. Deleting a deployment can take 15-20 minutes, after which it will disappear from your deployments list.
GRAX uses the access granted to your Cloud Platform to manage your deployment of the GRAX Application; This responsibility includes creation, monitoring, and maintenance of the infrastructure. As GRAX launches new features and cloud platforms release new versions of resources, GRAX will apply necessary infrastructure updates and improvements to bring you the most cost effective and secure deployment possible.
The specific resources needed by the GRAX Application varies by Cloud Platform and will change over time as those platforms update their offerings and features are added to the GRAX Application. For example resources, you can review our and suggestions on account auditing are discussed .
Compare the security profile and total cost of ownership (TCO) of these two options:
a system configured and updated with machine-to-machine automation
a system that requires direct access by many people or teams to set up and update
The former requires 0 people in the process, takes 30 minutes for the initial set up, and is automatically updated with security improvements over the entire lifetime of the system.
The latter can take many people weeks in the initial process to set up and weeks again to find the right people to perform security updates. It adds new risks of many people having access and passwords to systems, making configuration mistakes, and delaying security updates.
Multiply this by every additional system you create to backup additional sandbox and production environments and every security update required over the years of maintaining a system; you'll see that the security profile is significantly higher and the TCO is significantly lower by automating everything.
GRAX maintains isolated accounts with cross-account automation for all "GRAX Cloud" environments, and recommends the same exact security best practices and service to self-managed customers.
To create and continually manage deployments, GRAX requests a high level of continual access to cloud providers.
Creating resources and automatically updating resources for maintenance, security, and architecture improvements requires a high level of permission. Granting cloud platform managed policies like Administrator and Owner roles are the most straightforward way to guarantee everything works continually and allows GRAX to administer your deployment with minimal and manual intervention by your Operations teams.
But all permissions are ultimately in your control. If you no longer wish GRAX to have access to the Cloud account dedicated to the GRAX Application, the associated roles and principals can be destroyed. However, GRAX cannot manage your deployment by providing support, patching, updates, improvements, or monitoring for infrastructure deployed in Cloud environments that we do not have access to or to which access was prevented for an extended period of time, even if access is restored.
If your security policies don't allow cross-account access or require permissions that are not suitable to create and update GRAX resources, self-managed deployments do not require granting any access to GRAX.
At GRAX, information security is job number one. We have designed security into every layer of our product and system management. Cross-account access, combined with fully automated system setup and updates, provides the best security for all our customers and their sensitive data. GRAX uses the following best security practices:
Account isolation eliminates the risk of GRAX systems accessing other systems and data and vice-versa. GRAX requires that you run in an isolated account. Our certified templates provide further isolation at the VPC, EC2, database, and storage layers.
Automation eliminates configuration mistakes on first setup and enables fast delivery of updates for critical security improvements.
Automation removes people from the process; people are prone to make configuration mistakes and can be slow to apply security updates. Configuration mistakes and running outdated components are in the top 10 application security risks.
GRAX utilizes Terraform for the deployment of all infrastructure. The Terraform modules are available on request for review.
Password-less roles eliminate the risk of leaking credentials and guarantee only authorized machines have access to systems and leave an audit trail.
This eliminates static credentials that can leak and need to be rotated. It improves the ability to audit, where any access to your account other than the GRAX role, and any access to your bucket other than the GRAX Instance role, can trigger security review.
All cross account API calls are logged by AWS to CloudTrail. These logs always include the Role ARN and required Role Session Name, both of which include "GRAX". With the cross-account role, anything other than the GRAX role in CloudTrail logs is suspicious.
You can set up CloudWatch alarms for CloudTrail events to filter events and send notifications when anything other than the expected roles access your systems.
GRAX always leaves you in total control. At any time you can remove the cross-account role with the IAM Delete Role operation. Removal of GRAX's access to manage your applications and infrastructure constitutes a termination of GRAX's responsibility to manage, patch, upgrade, and monitor your deployment. If you remove GRAX's access, you are responsible for the security and maintenance of your deployment as well as all future upgrades. GRAX does not guarantee that a deployment can be restored to a managed state after access has been removed for any period of time.
If GRAX discovers that access has been removed, GRAX will notify the applicable application owners repeatedly over a reasonable period, but has no means to restore access independently.
Scroll down to the section titled "API Key"
Click Reveal
Copy the API key
On the GRAX Platform team you'd like to use for creating a deployment, navigate to the Connections tab and click Connect Heroku. Fill in the following values:
API Key: Use the API key from the Heroku Dashboard
Click Save to save the connection.
Once a Heroku Account has been connected a Deployment can be created. Navigate to the Deployments tab and click New Deployment. In the Advanced Settings, fill in the Heroku Team and Space names:
Enterprise Team Name: enter the Heroku Team Name
Enterprise Space Name: enter the Heroku Space Name
Click Save to create the deployment.
Setting up an Azure Service Principal is required to allow GRAX to manage infrastructure in your Azure account. This involves a few more steps than the AWS setup, but those steps are outlined below for both the Azure Portal and the Azure CLI.
Navigate to the and login with a user that has the necessary permissions to create service principals.
Search for and open the App Registration service.
Click New registration.
Open the Service Principal you just created in the Azure Portal.
Click Certificates & secrets.
Click New client secret.
Name the secret 'GRAX' or something similar in accordance with your business' naming conventions.
Navigate to the subscription you wish to deploy GRAX into.
Click Access control (IAM).
Click Add role assignment.
On the GRAX Platform team you'd like to use for creating a deployment, navigate to the Connections tab and click Connect Azure. Fill in the following values:
Tenant ID: Use the Directory (tenant) ID value from the App Registration.
Subscription ID: Use the subscription ID of the Azure subscription you wish to deploy into.
Client ID: Use the Application (client) ID value from the App Registration.
Click Save to save the connection.
az)First, ensure that you are logged in:
Note: In the above JSON, id represents your Azure subscription id.
Next, set your active subscription:
Then, create a Service Principal to allow GRAX to manage infrastructure:
This returns the required authorization data for your Service Principal, as JSON.
Now you need to enter the following values into your Azure Connection details:
Click .
Fill the values as follows:
Tenant ID: Use the "tenant" value from the JSON.
Name the team 'GRAX' or something similar in accordance with your business' naming conventions and click Register.
Copy the Application (client) ID and Directory (tenant) ID values from the Overview page to a safe location for later use.
Copy the Value of the secret to a safe location for later use.
Owner role under Privileged administrator roles.Click the Members tab then search for and select the Service Principal you created earlier.
Use the Review + assign tab to save the role assignment.
Client Secret: Use the Value of the client secret you created.
Subscription ID: This is your Azure subscription id.Client ID: Use the "appId" value from the JSON.
Client Secret: Use the "password" value from the JSON.
Click Save
az login[
{
"cloudName": "AzureCloud",
"id": "subscrip-abcd-abcd-abcd-abcdabcdabcd",
"isDefault": "true",
"name": "Pay-As-You-Go",
"state": "Enabled",
"tenantId": "tenantab-abcd-abcd-abcd-abcdabcdabcd",
"user": {
"name": "[email protected]",
"type": "user"
}
}
]az account set --subscription="${id}"az ad sp create-for-rbac -n "GRAX" --scopes "/subscriptions/${id}" --role "Owner"{
"appId": "appidabc-abcd-efgh-abcd-efgh-abcdabcdabcd",
"displayName": "John",
"name": "http://example.com",
"password": "password-abcd-efgh-abcd-efgh-abcdabcdabcd",
"tenant": "tenantid-abcd-efgh-abcd-efgh-abcdabcdabcd"
}
