Secrets

[MrDuck]

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?

[jgomes]

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

[NeilPalmere]

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.

[jgomes]

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.