CloudTruth Documentation
Sign InAPIIntegrationsGitHubVisit our website
  • Overview
  • Getting Started
  • Architecture
    • 🔒Security Overview
  • Copilot
  • 🏢Org management
    • Account Setup
    • Access Control
      • 🔑API Tokens
      • 🌐Protecting Projects and Environments
      • 👥Users
    • Audit Log
  • 🛠️Config Management
    • Projects
    • Parameters
      • Sharing Config Data
      • Parameter Management
        • Internal Values
          • Dynamic Values
        • External Values
          • Terraform Remote State Files
        • Parameter Override
        • Environment Value Override
      • Parameter and Parameter Value Inheritance
      • Value Comparison
      • Value History
      • Value Validation
      • Value Expiration
    • Environments and Tags
    • Templates
      • 📒Sample Templates
    • Actions
      • Import Actions
      • Push Actions
    • CLI & API
      • CloudTruth CLI
      • Rest API
    • Integrations
      • Argo CD
      • Atlassian Compass
      • AWS
        • AWS Connection
        • AWS Role
          • CloudFormation
          • Terrraform
          • AWS Console
        • Parameter Store (SSM)
        • S3
        • Secrets Manager
      • Azure Key Vault
      • Bitbucket Pipelines
      • Docker
      • Docker Compose
      • GitHub
      • GitHub Actions
      • GitLab
      • Harness
      • Jenkins
      • Kubernetes
      • Pulumi
      • Terraform
      • Terragrunt
      • Explorer
      • Circle CI
    • Events, Notifications, Webhooks
    • Types
  • 🔎REPORTING
    • Compare
    • History
    • Expirations
  • 🚀PRODUCT
    • What is CloudTruth?
    • Interactive Demo
    • Kubernetes
    • Terraform
    • CI/CD Pipeline Configuration
    • Cloud CMDB
    • Secrets Management
    • GitOps
    • Our Manifesto
    • Open Source
    • FAQs
    • Our Mission
  • 📚Reference
    • 🎓Quick Start Videos
      • What is CloudTruth?
      • CloudTruth in Action
      • Environments and Projects
      • Secrets, Parameters, ENV variables
      • Audit Logs, RBAC, SSO
      • Containers - Kubernetes, Docker
      • Infrastructure as Code (IaC) - Terraform, Cloudformation, CDK, Azure Bicep, Pulumi
      • CICD Pipelines - GitHub Actions, ArgoCD, Jenkins, CircleCI, Harness, GitLab Pipelines
      • AWS Videos - Secret Manager, Parameter Store, S3, IAM
      • Azure Videos - Azure DevOps, Azure Bicep, PowerShell
    • Knowledge Base
      • Best Practices
        • Versioned Releases
      • CLI
        • History comparison of deleted parameters with null values
      • Integrations
        • Advanced AWS IAM policy permissions
        • K8s pull image from private Docker registry
        • S3 Region Selection
      • Templates
        • Templates render quotations in key values as quot
    • Roadmap and New Features
    • JMESPath Reference
    • REST API
Powered by GitBook

Copyright© 2023 CloudTruth

On this page
  • Creating Projects
  • Editing Projects
  • Project Inheritance
  • Copying a Project
  • Deleting a Project

Was this helpful?

  1. Config Management

Projects

PreviousAudit LogNextParameters

Last updated 1 year ago

Was this helpful?

A CloudTruth project allows you to isolate parameters and templates for specific use cases within your organization.

Each CloudTruth Organization starts with a default project MyFirstProject.

Here are a few general ideas on how to use projects:

  • A project should represent the component you are trying to configure. This is frequently 1:1 with a git repo.

  • The parameters/secrets/templates in a project can be thought of the configuration interface for a component. Sometimes it is worthwhile to segment out a project further to segregate data further, e.g. the parameters need for tooling, or pipelines vs. the app itself. Environments represent an implementation of the configuration interface by supplying the concrete values for that environment

  • Using a project hierarchy as a means to group similar components together to enable sharing/linking of data common to those components. Projects higher up in the hierarchy would thus not represent individual components but a common ancestor to house common configuration data.

Creating Projects

Click Create Project from the global context at the top of the page, or use the global Create dropdown to locate and select the Create Project item.

Provide the Project a name, and any other optional values then click Create Project.

  • PROJECT NAME - Typically the name representing an application or service (required)

  • PARAMETER NAME PATTERN - A regular expression parameter names must match, e.g. FOO_.* will require every parameter name to start with: FOO_ (optional)

  • DESCRIPTION - Further describe the project's purpose (optional)

Editing Projects

All projects accessible by a user are represented on the page via the Projects tree:

From here you can edit the main attributes of a project.

  • PROJECT NAME - Typically the name representing an application or service (required)

  • PARAMETER NAME PATTERN - A regular expression parameter names must match, e.g. FOO_.* will require every parameter name to start with: FOO_ (optional)

  • DESCRIPTION - Further describe the project's purpose (optional)

Project Inheritance

We provide the ability to inherit another project's parameters as part of a project inheritance tree.

This allows you to define a base set of parameters for your applications and share them across all of your projects. Child projects also allow overriding parameters at a specific project and environment level giving you complete control over your app configuration.

If a project's inheritance needs to change, the project can be manually moved to its new location via the Project Tree. Simply click and drag the project from its current location to the destination location. Projects can be moved to the top-level or to any child position:

Be sure to understand the ramifications of moving a project as will change the project's dependencies

Moving a project will include a confirmation request to make sure the move was intended where the message varies depending on what type of move is being made, moving a top-level parent project to become a child project:

Also, moving a child project to another location will indicate the dependency removal:

Copying a Project

Copying a project will copy all parameters and templates associated with the source project. This can be quite useful, especially when you have several similar projects. A project template or "gold master" can be created and labeled as such to avoid any boilerplate between projects.

If the project being copied has dependents, a similar dialog will be displayed adding the ability to copy the dependent projects (which will also copy every project's associated parameters):

  • PROJECT NAME - Typically the name representing an application or service (required)

  • DESCRIPTION - Further describe the project's purpose (optional, the visible placeholder is the default)

  • COPY DEPENDENTS - Checking this option will copy the original project and any of its dependent projects to the new project. Currently we do not provide the ability to re-name any copied dependents. They will be created with the same name with a short hash appended, e.g. MySecondProject-b30c3498

Deleting a Project

Deleting a project deletes all parameters and templates that exist within that project!

Clicking Yes, delete will remove the project along with any associated templates and parameters.

PARENT PROJECT - Nest the new project under a higher-level project to inherit the parent project's parameters, see below (optional)

Clicking on a project's edit icon will open the EDIT PROJECT dialog.

Clicking the symbol will open the COPY PROJECT dialog.

PARENT PROJECT - Nest the new project under a higher-level project to inherit the parent project's parameters, see above (optional)

Clicking the symbol will present a confirmation dialog:

🛠️
Project Inheritance
Project Inheritance