Migrating from Torus to Manifold

This documentation describes how to migrate your stored credentials from Torus to Manifold, and explains some Manifold concepts that may make your migration easier.

Manifold CLI

Like Torus, the Manifold CLI manages secrets and can fit into your workflow with manifold run injecting your secrets into your runtime environments.

Getting and Installing the CLI

You can download and install the latest version of the CLI with the command:

curl -o- https://raw.githubusercontent.com/manifoldco/manifold-cli/master/install.sh | sh

Or, if you are on MacOS, you can install Manifold-CLI with Homebrew:

brew tap manifoldco/brew
brew install manifold-cli

Registration and Logging in with the CLI

Using a username and password

To register for an account using a username and password, use: manifold signup. Once registered and verified, you can log in with the command: manifold login

Environments and Projects

Manifold does not have the concept of Environments. Instead, Manifold has Projects, which are a grouping of Resources. Some Resources may be common to multiple Projects For example, you might have a “Logging” project, which has Resources for logging throughout your infrastructure and across environments, and each Environment usually needs a separate set of Resources (with development credentials, e.g. a development database), Environments and Project serve a similar purpose in Manifold.

To account for this, it’s important to think about your Project structure in Manifold, to represent the structure of your overall infrastructure for your team. Our integrations work across projects, so collecting Credential information on Resources across Projects is easy. One common pattern is to have any Resources that would cross-Projects (and environments) in a common Project (or multiple common projects). Any common configuration can be stored in these common Projects, and access across-project.

In most cases, if you use a wildcard pathexp in Torus, you can accomplish the same thing with a common Project in Manifold. If you had a structure in Torus such as:

/bestorg/awesome-cms/staging/content_api_key
/bestorg/awesome-cms/prod/content_api_key
/bestorg/project/*/database_url

this might translate into the following structure in Manifold:

bestorg
  - project-staging
    - content_api_key
  - project-prod
    - content_api_key
  - project-common
    - database_url

Creating a Project

To start, it is probably easiest to create a project for each project/environment. This would mean environments in Torus would be mapped to a project <project>-<env> (e.g. my-awesome-project-dev).

You can create a project with the manifold projects create to create a new project. You can run the command without parameters to create a project interactively, or use manifold project create my-awesome-project-dev to create a new project called “my-awesome-project-dev”.

Creating a Resource

Resources allow you to manage services and Credentials for those services. For migrating to Torus, we will only talk about Custom Resources, but Manifold also offers a wide range of partner services with convenient billing and management of those services.

Migrating Credentials

To migrate Credentials, we will create our Project structure in Manifold. Manifold does not have the same idea of Environments from Torus, however the patterns can be easily replicated.

Organizations to Teams

Manifold’s concept of organizations are called Teams. Teams have separate projects, resources and billing (for partner services). Users that are a member of each team have permissions levels for that team. The permission levels are for the Team itself, and any projects or resources within that Team. The permission levels are:

  • Read
    • Able to read resource information for the Team, such as cost and basic information about Resources and Projects
    • Not able to read Credentials
  • Read Credentials
    • All the permissions of Read, plus with the ability to read credentials
  • Write
    • The ability to Read and Write to the team. This includes; adding, removing and resizing Resources; adding, removing or updating Projects; using Single-Sign-In to access Resources, and reading and updating Credentials values
  • Admin
    • All the Permissions of Write plus the ability to manage a Team’s users, permissions and billing profile.

To create Teams, use the manifold teams create command. If a no Team name is given as a parameter, then creation will be interactive. To non-interactively create a team, pass a name as a parameter to the command: manifold teams create my-great-team.

To list your Organizations in Torus, use torus orgs list.

Team Role-Based Access Controls

Within Teams, you can organize your team members to have various levels of permissions. For example, if you had development, stage and production environments, for which your team had varying levels of access to the credentials, you could create a team for each environment, and assign only Read credentials to users who can see resources, but not credentials, and Read Credentials or above for anyone who should be able to see that teams credentials.

For example, using the example of having a Development and Production environment, you would have the teams

  • AwesomeCompanyDevelopment
  • AwesomeCompanyProduction

and you have the following users and their organizational roles:

  • UserA -- Jr. Software Engineer
  • UserB -- Support Staff
  • UserC -- Technical Operations Engineer
  • UserD -- API Token

they could have the following roles in each above team:

  • AwesomeCompanyDevelopment
    • UserA: Write
      • Able to read and write credentials, see resources
    • UserB: Read
      • Able to see resources, but not credentials
    • UserC: Admin
      • Able to manage users and permissions, able to read and write credentials, see resources
    • UserD: Read Credentials
      • Able to read credentials
  • AwesomeCompanyProduction
    • UserA: Read
      • Able to see resources
    • UserB: Read
      • Able to see resources, but not credentials
    • UserC: Admin
      • Able to manage users and permissions, able to read and write credentials, see resources
    • UserD: Read Credentials
      • Able to read credentials

In the above example, UserC has access to all of the projects as an Admin, and the API Token UserD can read credentials in all projects. In the Development environment team, UserA has the ability to read and write credentials, but only the ability to see resources in the Production environment team. UserD has the ability to see the resources in both teams, but cannot read or write credentials.

Environments to Projects

First, we must create Projects in Manifold for each Project/Environment combination in Torus. To list your Projects in Torus, use: torus projects list. To list Environments for each Project, use torus envs list -p <project>. Once you have your Project/Environment combinations, you can use manifold projects create <project>-<env> to create your environmental projects in Manifold.

Creating Custom Resources

Credentials are stored on Resources. In Manifold Resources might mean a partner service, or, as in this case, might mean a Custom Resource, which stores Credentials for services that you use within your infrastructure.

How you create and organize the Custom Resources within a Project is up to you. You can just as easily put all the Credentials in one Custom Resource, and then manifold export on the Project or Resource will give you everything you need. Alternatively, you can organize your credentials by service, where manifold export on a Project will export the credential values for all your Resources within that Project.

To create a Custom Resource in Manifold, use: manifold create -c. This will allow you to interactively create a new Custom Resource. To pass a team to create the Resource in use -t. To pass a project to create the Resource, use -p. To create a Custom Resource non-interactively, pass the name as part of the parameters: manifold create -t <team> -p <project> <resource-name>.

Uploading Credentials

To upload your Credentials to your Custom Resource, use manifold set -r <resource-name>.

You can set credentials from Torus in Manifold by using:

for i in `torus export --org <org> -p <project> -e <env> | sed -e 's/"//g'`
do manifold config set -r <manifold-custom-resource> $i
done

Manifold Concepts

Manifold has a similar structure to Torus, and these many concepts are already ones you already know for Torus.

Credentials

Credentials are encrypted key-value pairs that store secret information. To access credentials, you can use our dashboard, CLI, Kubernetes integration, Terraform integration or Laravel integration.

Resources

Resources are the basic object about a service in Manifold. There are two types of Resources, and Resources have Credential information associated with them.

Provider Resources

Provider resources are services that we offer through Manifold. They are developer services you may already use, or may find useful in new or existing applications. Provider Resources already have Credentials provided for accessing those services.

Custom Resources

Custom Resources are resources that you manage directly, rather than be a provider-service that already exists in Manifold. You can use Custom Resources for storing all types of credentials as encrypted key-value pairs.

Projects

Projects are a collection of Resources whose Credentials can be exported en masse.

Teams

Teams are like your Torus Organizations and Teams. Teams are a collection of users that have projects and resources in them. Each user can have s different level of permissions on the team, but all users can at least view the project and resource information for all the projects and teams in that Team.

API Tokens

API Tokens are used for programmatic access to the Manifold service, similar to Machine Tokens in Torus. Currently, API keys must be created using the CLI with: manifold tokens create Additional Documentation on Manifold Additional documentation on Manifold can be found at https://docs.manifold.co.

Torus F.A.Q.

How do I reset my Torus password?

Due to the nature of the client-side encryption we can't reset your master password.

If you had more than one admin in your organization, you can sign up for a new account and then have that admin invite you back to the organization. if you were the only user in your organization, then unfortunately we cannot recover the contents for you (we simply can't access any of the data stored -- it was encrypted with your password).

How do I delete my Torus account?

To delete your Torus account, please contact us at support@torus.sh.