Secrets

cancel
Showing results for 
Search instead for 
Did you mean: 

Secrets

L1 Bithead

How is everyone else doing secrets?

It seems odd to me that everything that might use an API key needs to be an integration instead of an automation.
You can't seem to easily hide plain-text apikeys from an automation at all.

 

For example:

I have a Contact List for emergencies:

I have an API key, that I use to query the owner of certain cloud instances pull the name down, and auto generate an email.

all I want to do is hide the API key from being plain-text in the code. The contact name, is also based on other integration JSON attributes on where to look. It seems like I would need to build an integration, to look at another integration to work?

The automation already works, but now to set this up as an 'integration' seems like an additional 10 steps that seem silly? am I missing something?

 

3 REPLIES 3

L2 Linker

Hi Thomas,

 

It is correct the platform is geared towards using integration to safely store and handle credentials. Integrations come with other features like integration context to store instance objects and methods like fetch. 

Yoda Speaks is a good tutorial on creating your first simple integration - https://xsoar.pan.dev/docs/tutorials/tut-integration-ui

That said, if the credentials is not very sensitive you can still leave in automation code. You can use RBAC to restrict access for less privileged users to see automation IDE and code.

 

There is also a automation setting argument tick box called ‘sensitive’. When set, it will popup a password box at time of run for analyst to type in password, and thus not stored in code. This would be for on demand playground CLI or war room.

 

cheers

L0 Member

I was looking at this again myself two weeks ago when using a specific endpoint in MS Graph API.

It seems to be set up this way by the core design philosophy of the XSOAR platform:

  • Automations should be reusable code that can run completely within the platform
  • Integrations are code and creds that may touch other systems to perform API actions (like fetching incidents)
  • Integrations must be self-contained and should be single-purpose
  • An integration should have all code it needs to perform its tasks 
    • An automation can call integration functions, Integrations can't call automations
    • Integrations shouldn't be able to use other integrations either

Therefore, there should be no need for an automation to store any credentials because they'd be stored in the integration with the external platform. The call to the external platform would have the credential usage abstracted by the integration with the automation getting the results of the API action.

 

In practice, spinning up a whole integration to make one GET request feels a little silly but if you want to protect your creds there isn't too much choice.

L2 Linker

Hi, just checking-in on this older post that you had you question resolved.

If any posts have helped you resolve your issue, please kindly accept one of the solution answers.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!