Secure access managers

Secure access managers

SSMCM integrates with secure credential managers for registration and consultation operations.

Secure access managers supported

For now, the only supported Secure Access Managers are as follows:

There are 2 types of permissions for organization credentials:

  • SECURE_ACCESS_MANAGER_READ: secureaccessmanager:read: Allows the use, listing and viewing (without the values) of credentials
  • SECURE_ACCESS_MANAGER_WRITE: secureaccessmanager:write: Allows complete management of credentials

When adding a manager, the following fields must be filled in:

  • Organization (required)
  • Name (required)
  • Type of manager (required. For now, the only providers allowed are Hashicorp Vault Community and Enterprise)
  • Namespace locator (required, only visible in Enterprise)
  • Static credentials (it is mandatory to configure at least one type of credentials)
  • Secrets engine path (required)
  • Secret locator expression (required)
  • OTP credentials
  • SSH Secret Engine Path (required)
  • Role name (required). Accept expressions.
  • Additional roles available (optional). Accept expressions.
  • URL of the server with which the integration will be performed (required)
  • Credentials (required)

Available expressions

  • organization.id
  • organization.name
  • account.id
  • account.provider
  • account.alias
  • account.name
  • account.tag
    • Example {account.tag:tag_key}
  • account.azure_tenant_id
  • account.gcloud_folder_path
  • account.aws_organization_account_id
  • organizational_unit.id
  • organizational_unit.name
  • azure_tenant.id
  • azure_tenant.tenant_uuid
  • azure_tenant.tenant_name
  • azure_tenant.tenant_domain
  • inventory_item.resource_id
  • inventory_item.region
  • inventory_item.tag
    • Example {nventory_item.tag:Environment}

Locators support special characters ($%&?¿#Ç...) but some may cause integration to fail. It is advisable to use numbers, letters, middle and low hyphens.

Before SSMCM can connect to the secrets manager to obtain the information, credentials must be specified, which must be previously configured in the key storage system used by SSMCM. These credentials can be specified at 2 levels: at the secret manager level, or at the account level, depending on the project-level or manager-level permissions granted to the credential.

When you save the changes, the form will reappear with read-only fields and a button to check the configured static engine.

The integration button verifies the generation of configured credential types. If any field is modified, it is deactivated. You have to press on send to activate it again.

Account integration

Once the manager has registered, it is necessary to configure the accounts to use it; To do this, we must go to the accounts section, edit the corresponding account, and select the secret manager, indicate the corresponding project of the account in the secret manager, and, optionally, The credentials that will be used by those configured in the manager, or if you want to use others.

When you associate a secrets manager with an account, you can associate the managers of the organization owner of the account and those of the MSP organizations to which it delegates responsibilities (administration and infrastructure operations), if this delegation of responsibilities has been specified.

Once the manager is assigned to the account, columns are available to display information from the manager of each account:

Information about Secure Access Managers (number of alerts associated with an account, and associated with an inventory item) is updated every 30 minutes.

Using credentials

It is possible to specify credentials at both the secrets manager and account level levels. Credentials must be specified in at least one of the two places. If credentials are specified in the account, they are used to connect to the account manager. secure access and being able to read or update credentials; If not, and credentials have been specified at the administrator level, then They will use those. If no credentials have been defined on either, a validation error will be thrown.

This allows you to have Secure Access Managers that use the same credentials for all accounts that are associated, or have different credentials per account for the same manager, for example, with different or specific permissions for the account.

When specifying account-level credentials, only those corresponding to the organization that owns the account, even if the associated secrets manager is a member of an MSP organization to which some responsibility has been delegated (administration and/or operations on infrastructure)