Automations

DevOps Secret Management module allows administrators to set up automation for active life-cycle management of secrets in applications like cloud secret management services such as Google Cloud Secret Manager, Azure Key Vault, AWS Secrets Manager, and others, as well as Kubernetes environments, configuration files inside servers, etc...

Through the usage of this automation, it is possible to connect to most environments and systems using a protocol-driven approach, where senhasegura DSM will reach those systems and environments through SSH, Windows RM & RPC, SQL, HTTP/S, and others, so it can run a series of pre-defined commands to manipulate secrets without the needing of manual configuration.

Automations are based on triggers that can be executed depending on the application and the monitored secret. DSM allows automation to run based on the following moments:

• Secret creation on a specific secret or application;
• Secret update on a specific secret or application;
• Secret activation on a specific secret or application;
• Secret inactivation on a specific secret or application;
• Authorization creation on a specific application;
• Authorization update on a specific application;
• Authorization activation on a specific application;
• Authorization inactivation on a specific application;

The automation module already has several predefined connectors to facilitate resource use, but new ones can be easily created from templates.

Automations can be used to - but not limited to these cases - add, update, and delete secrets:

• in database;
• in an application or server configuration files;
• in the secrets of Kubernetes, OpenShift, or another Kubernetes service;
• in cloud services like Google Secret Manager;

Requirements

• Have an Application or Secret created
• A credential that will be used to execute the automation action
• A device where will be executed the automation
• Execution Template

Register an Automation

1. Access DevOps Secret Manager ➔ Automations ➔ Automations
2. Click on the report's ⋮ button, then click on the +New
3. Fill in the automation general fields:
   • Name*: Automation name used internally for identification and reports
   • Enabled*: Whether the automation is available for use or not
4. In the Information tab, fill the following fields:
   • Description: A detailed description of the automation
   • Tags: List of tags to further identify the automation
5. In the Trigger tab, fill the following fields:
   • Trigger*: The event triggers which start the automation process. One or more can be selected
   • Then choose:
     • Application: One or more applications to be observed by the selected triggers
     • Secret: One or more secrets to be observed by the selected triggers
6. In the Action tab, fill the following fields:  
   
   
   • Plugin: Protocol or application which will execute the selected template
   • Template: Template containing instructions that will be executed on the target application
     Info

     You can click on the + to create a new template.
   • Device: Target device which senhasegura DSM will connect to through the selected plugin to execute the template
     • Credential: Credential is used to connect to the device and execute the template
7. To finish, click on Save.

View an Automation

To see a list of all configured automation inside DSM, follow the menu DevOps Secret Manager ➔ Automations ➔ Automations.

On this screen, you can view registered automation with extra information such as name, tags, automation applications, automation secrets, creation date, last execution date, and whether or not the automation is enabled.

View an Automation Execution Status

To see all the automation executions statuses, follow the menu DevOps Secret Manager ➔ Automations ➔ Executions.

On this screen, you can view the automation execution status with extra information such as automation name, trigger, target device, status, and creation date.

 

 For more details about the execution, click on the Details action for the selected execution.

View DSM Events

Automation events

Through DevOps Secret Manager ➔ Event ➔ Audit Tracking, we have a log report called DSM Logs.

• Code: the ID generated by the creation of the log
• Operation: which operation was generated in the system
• Entity: what type of functionality is being used
• Entity code: the entity functionality ID
• Entity Name: the name defined when the entity was created
• Origin: which module functionality is being used 
• User: who executed the action
• Username: the username in senhasegura
• IP: the IP of the device that generated the log
• Date and time: view when the log occurred
• Action: The Audit tracking window will open by clicking on the magnifying glass icon. It contains detailed information on the operation that generated a log in the system to audit information changes.

View automation logs

In the module DevOps Secret Manager ➔ Events ➔ API Logs:

• Event: information about the events (reading, create, delete and update)
• Answer: if the API request is successful, code 200 will be displayed, and in case of an error, the code displayed will be 403
• Entity type: the defined type of entity
• Entity name: the name defined when the event was created
• Application ID: the application identification number
• Authorization: the permission generated for the access
• IP: the user's device on which the change was performed
• Date and time: The day and the hour when the function modification was performed

Inject and rotate secrets in Azure Key Vault, AWS Secret Manager, Google Secret Manager, and Kubernetes

Create an automation following the steps inspired by the Create automation section above, and on the Action tab, select the model corresponding to the solution you want to integrate:

Azure Key Vault

To integrate with Azure KeyVault, follow these steps:

1. While creating a secret, fill in the field with the desired credentials and enter the Key/Value values

• AZURE_CLIENT_ID: Unique identifier assigned to the application or service that wants to access Azure resources. It is used to authenticate the application or service.
• AZURE_KEYVAULT_NAME: Name of the Azure Key Vault, which is used to store and manage keys, passwords, and other secrets.
• AZURE_RESOURCE_GROUP: Logical group of Azure resources, which includes related services such as virtual machines, storage, and networking.
• AZURE_SECRET: This is the secret key the app or service uses to authenticate and access Azure resources.
• AZURE_SUBSCRIPTION_ID: Unique identifier for an Azure subscription allows a user to access and manage Azure resources.
• AZURE_TENANT: This is the unique identifier of the organization or company using Azure, which is used to authenticate users and Azure resources.

2. Create automation as described in the respective documentation using the Azure KeyVault template and the Ansible execution plugin.

3. When defining the Trigger and executing the parameterized action for activating it, the secret will be rotated/injected into the safe.

AWS Secret Manager

In the actions tab, select the AWS Secret Manager - Inject Secret template to inject and rotate the secret. After Execution, go to the AWS Management Console, search for Secret Management services. In the list of secrets, click on Secrets and click on the item created by senhasegura to see the details as in the following example:

 

Google Secret Manager

In the actions tab, select the Google Secret Manager - Inject Secret template to inject and rotate secrets. After execution, access the Google Cloud Console, select the project in the upper selection tab and in the side menu, access Security ➔ Secret Management, In this list of secrets, click on the item created by senhasegura to see the details as in the following example:

 

Kubernetes

In the actions tab, select the Kubernetes - Inject Secret template to inject and rotate the secret. After Execution, go to the Kubernetes Cluster where the secret was created and view the secret with the kubectl describe secrets/[secret_name] command as in the following example:

 

Automatically provision Applications POST method API

POST /iso/dapp/application)

Add cloud_profiles parameter:

• Name: cloud_profiles
• Type: string[] (Array of strings)
• Required: no

Add credential_profiles parameter:

• Name: credential_profiles
• Type: {device: string, profile: string}[] (Array of objects with device and profile keys)
• Requerido: no

        {device: "192.168.0.1", profile: "cassandra_profile"},

        {device: "192.168.0.2", profile: "redis_profile"},