what is sprawling and how to protect your secrets

Hi Everyone,
Though this is a technical stuff, If you want you can take it to the life as well
So, Let’s start and pick up the grains one by one.

What is Sprawling ? 🤔

By word it is an adjective which means “spreading out over a large area in an untidy or irregular way”.

So now what is secrets sprawling ? 🙄

When everybody knows what needs to be very personal or when it is not a secret anymore.
It is the problem of secrets sprawling.

It is harmful to an individual person, organisation and even to the software applications.

Here we’ll focus on identifying the areas of secrets sprawling for any software application.

How secrets sprawling is a problem for software industries ? 🕵

The previous application architectures are fading as users prefer great user experience and service availability.
In this growing era of cloud platform technology, where we can feel the shift towards micro service architecture enhanced deployment tactics and server management.

Access Control plays an important role.

In this case if you are a part of any software development/deployment/suport team and have a generic username & password to access the server logs or any other entity hosting the application.
Don’t worry you are already a part of sprawling where anybody can access the server using those generic username and password that is shared by you or your team member in whom so ever condition.

let us also look at the other aspect where you have a client-server architecture and your server application uses a set of credentials to login and perform a set of activities with the database.
also now you have different instances of the same application running at different servers.
This is also a case where your whole system and data is more prone to malicious activities.
simply because when one of your server is attacked the credentials can be used to connect and operate data-storage in an uncontrolled manner.

Let’s hear this man video. 👀

Do you make your application read config files containing database/third-party credentials in order to connect with the services ?

This is no different to the case we highlighted above. As the team of developers and testers already know what is written there in those files. Later when they leave the team, they can have FUN with it

(😀 may be like a relationship that didn’t work out and I want a revenge ! ),

Also you will never know that from which replica server the data-storage has been attacked, and by the time you track the source of the machine it would be too late to get out of the mess.
(Yes, It’s gonna be a deep shit).

Does it affects my CI/CD as well ? 🤔

Yes Dear,
If you have parameters that are meant to be secrets and you are keeping it on you CI/CD, Config file or github or google drive. You are sprawling them.

The solutions !! 😇

Now when we know what can be done using the secrets and where it can be gained from it’s time to look for a solution.

The most popular solution to this problem it to have a proper fine grained access management in place(Which defined who can access what).
This thing can surely reduce the amount of sprawling but how to make it 0% ?
don’t store your application secrets over your GitHub/Gitlab CI/CD variables , config files or environment variables.

Then where to store it ?

Use a sophisticated system to store secrets (a list of few most popular are listed below sorted as per the popularity and features they provide)
- Hashicorp vault
- AWS Secrets manager
- Square Keywhiz
- Confidant
- StrongBox
- Docker secrets

Yes, There are some great tools few supported by the open source community so it’s free to use them.

What are The features and how they can help in solving this sprawling ? 🤓

-It provides secrets management with defined access control policies.
-Your applications can get credentials to connect with database dynamically and if you have multiple instances of the same application each instance will get it’s unique credentials, So you can identify which instance performed what operation.
-It provided out of the box standard cryptography, So no need for application development team to write crypt logic( which can be known to deviate from standard coding practices ).
-you can revoke the access of any individual leaving the team of any application instance which you found malicious.

It’s better to use these secret management tools as they are already compliant with various coding standards and even provide a high availability in order for the secrets to be available to the authorised resource/person only.

Let’s get rid of sprawling and hit him with a punch ! 👊🏽 😠

I’am a reader, explorer, techie all at the same time. Say “hi” via email: rahulkohli23@outlook.com