Create Secrets
Secrets are the information we want to share, between identities.
They are deliberately kept simple in CryptVault.
There are two types of secrets.
- Text
- JSON
For our example identities, there are two types of secrets:
- Shared between Search-Team and A-Team
- self-administered by the A-Team for an application server (we call this application A-Service).
the search team side
On the search team side, they create access for the A-team to certain big data information.
The exact permissions are not relevant here. The important thing is to set a login condition for the A-team.
resource "cryptvault_cloud_value" "a_service_connection_string" { name = "VALUES.search_team.a_team.a_service.connection_string" vault_id = cryptvault_cloud_vault.my_vault.id creator_key = cryptvault_cloud_keypair.Search_Team.private_key passframe = "connection_string_secret_with_password_etc" type = "String"}
the A-Team side
The A-Team also creates secrets for the A-Service.
resource "cryptvault_cloud_value" "a_service_admin_key" { name = "VALUES.a_team.a_service.admin_key" vault_id = cryptvault_cloud_vault.my_vault.id creator_key = cryptvault_cloud_keypair.A_Team.private_key passframe = "Some Secret" type = "String"}
resource "cryptvault_cloud_value" "a_service_email_connection" { name = "VALUES.a_team.a_service.mail" vault_id = cryptvault_cloud_vault.my_vault.id creator_key = cryptvault_cloud_keypair.A_Team.private_key passframe = "Some other Secret" type = "String"}
The A-Team will also create a new identity for the A-Service.
This identity will be used directly on the deployed service via the Higher Order Application. It should therefore have read-only access to the secrets in the CryptVault.
# Create a new identity keypairresource "cryptvault_cloud_keypair" "A_Service" {}
# Register Keypair to cryptvault.cloudresource "cryptvault_cloud_identity" "A_Service" { name = "A_Service" vault_id = cryptvault_cloud_vault.my_vault.id creator_key = cryptvault_cloud_keypair.A_Team.private_key public_key = cryptvault_cloud_keypair.A_Service.public_key rights = [ { # Team internal secrets right_value_pattern = "(r)VALUES.a_team.a_service.>" }, { # Search_team connection string right_value_pattern = "(r)VALUES.search_team.a_team.a_service.connection_string" } ]}
output vault_id { value = cryptvault_cloud_vault.my_vault.id}
output "A_Service_identity" { value = cryptvault_cloud_keypair.A_Service.private_key sensitive = true}
terraform apply
Get the output data with:
terraform output -json
the search team side
On the search team side, they create access for the A-team to certain big data information.
The exact permissions are not relevant here. The important thing is to set a login condition for the A-team.
vault-cli protected --creds .cryptvault/$VAULT_CLI_VAULTNAME/identity/Search_Team/key add value --name VALUES.search_team.a_team.a_service.connection_string --passframe connection_string_secret_with_password_etc
the A-Team side
The A-Team also creates secrets for the A-Service.
vault-cli protected --creds .cryptvault/$VAULT_CLI_VAULTNAME/identity/A_Team/key add value --name VALUES.a_team.a_service.admin_key --passframe 'Some Secret'
vault-cli protected --creds .cryptvault/$VAULT_CLI_VAULTNAME/identity/A_Team/key add value --name VALUES.a_team.a_service.mail --passframe 'Some other Secret'
The A-Team will also create a new identity for the A-Service.
This identity will be used directly on the deployed service via the Higher Order Application. It should therefore have read-only access to the secrets in the CryptVault.
vault-cli protected --creds .cryptvault/$VAULT_CLI_VAULTNAME/identity/A_Team/key add identity --name A_Service --r '(r)VALUES.a_team.a_service.>' --r '(r)VALUES.search_team.a_team.a_service.connection_string'