Identity Handling

Overview

This is an example of how to control access to Vault resources in a multi-team organisation.

Of course, the usage processes will vary from company to company and user to user. As Cryptvault.cloud is very flexible in its use, it should be possible for any organisational structure to integrate the product.

In this scenario, we show the most commonly used pattern:

• It is a specialised company
• There is a team that is the root administrator of CryptVault.
  • They structure the data inside the CryptVault.
• When a team needs access to data in the Cryptvault, they request it from the administration team.

The safest and easiest way to submit this request to the Administration Team is as follows:

• The team creates a key pair for itself

Terraform

  terraform {
    required_providers {
      cryptvault = {
        source = "cryptvault-cloud/cryptvault"
      }
    }
  }
  provider "cryptvault" {}

  # For this step not necessary but later needed for handle data
  data "cryptvault_cloud_vault" "OrgName" {
    id = "vaultid"
  }

  # Create a new identity keypair
  resource "cryptvault_cloud_keypair" "A_Team" {}

  # to show public key
  output "team_public_key"{
    value = cryptvault_cloud_keypair.A_Team.public_key
  }

terraform init
terraform apply

Cli

# init a local folder structure for vault by known vaultid
vault-cli local init --vaultName "OrgName" --id "vaultid"

# create a local keypair identity will be saved at local folder structure
vault-cli local create identity --name "TeamKeyPair"

• It requests access to resources in target areas. For example:

  (rwd)VALUES.domain-A.> and (rwd)IDENTITY.>

  and sends the public key with it.

Good to know

With this permission, the team can create more identities.

But only give newly created identities permissions lower or equal than VALUES.domain-A

• The administration team can now use this information to add a new identity to the CryptVault.

Terraform

  terraform {
    required_providers {
      cryptvault = {
        source = "cryptvault-cloud/cryptvault"
      }
    }
  }
  provider "cryptvault" {}

  # For this step not necessary but later needed for handle data
  resource "cryptvault_cloud_vault" "my_vault" {
    name  = "Org"
    token = "token_allow_you_to_create_vault"
  }

  # Load team public Key
  data "cryptvault_cloud_public_key" "A_Team" {
    public_key = "Given public key"
  }


  # Register Teamidentity at cryptvault and set rights
  resource "cryptvault_cloud_identity" "A_Team" {
    name        = "A_Team"
    vault_id    = cryptvault_cloud_vault.my_vault.id
    creator_key = cryptvault_cloud_vault.my_vault.operator_private_key
    public_key  = cryptvault_cloud_keypair.A_Team.public_key
    rights = [
      {
        right_value_pattern = "(rwd)VALUES.domain-A.>"
      },
      {
        right_value_pattern = "(rwd)IDENTITY.>"
      }
    ]
  }

terraform apply

Cli

# create vault and generate local datastrukture
# in our example allread done. just for the sake of completeness
## vault-cli create_vault  --vaultName="Org" --vaultToken="token_allow_you_to_create_vault"

# create a local keypair identity will be saved at local folder structure
vault-cli protected --creds "creator_key" add identity \
  --public-key="Given public key" --name="A_Team" \
  --r "(rwd)VALUES.domain-A.>" \
  --r "(rwd)IDENTITY.>"

This example shows how you can connect and authorise teams without sharing the private key, and still allow the team to create additional identities with restricted access.

This is often done via a git repo using a merge request. This is where teams enter their required permission configurations, which then need to be approved by an admin user.

It may then be worth using the Terraform provider in combination with a CI pipeline.