How to solve permission issues in CI / CD pipelines

DevOps teams are aware of the ways in which security concerns and processing issues can disrupt CI/CD operations. Operational obstacles that lead to miscommunication between team members and the broader organization are all too common in DevOps pipelines. One of the major operational issues DevOps teams face is permissions issues.

Permissions issues are a seemingly small, but significant, hurdle to smoothing the CI/CD pipelines. If you fail to address it, the result is a lack of coherence between development and organizational goals.

Here’s how to simplify these processes, enhance security integration within the broader CI/CD framework, and maintain strong security postures.

Pipeline Tools Review

The DevOps course contains several tools with different access needs and permissions. Jeremy Hess, Head of Developer Relations at Secrets management platform Akeyless, calls this the “Extension of Secrets.”

“The combination of proliferation of secrets and decentralization creates an operational burden, if not a nightmare,” Hess says. “For organizations operating in a cloud-native environment and traditional IT infrastructure, a redundancy issue is created due to managing their own secrets using different tools and cloud-native solutions.”

There is also the risk of these tools exposing user credentials and permissions to malicious parties. For example, configuration tools like Jenkins use plug-ins to determine access and deployment of the tool. Thanks to the connection with other pipeline tools, the credential details can be located in the configuration details.

Developer passwords are not visible on the front end but can be accessed from the system. Any user with Configure permissions can request and enter credentials into the agents. The result is that AWS keys, git credentials, and passwords are at risk.

What do I do:

  • The first step is to delete the encrypted secrets from the CI/CD tool files.
  • Distributing secrets among multiple tools’ configuration files also reduces the possibility of an attack while making it easier for the developer and engineer to access.
  • Password managers are also a good option, but check their integrity before implementing any solution.

Exercise least privileged access

Access issues often create a lot of frustration among DevOps teams as they have to allocate universal access to the majority regardless of a member’s role or function. While this situation encourages rapid development, it creates huge security problems.

It is difficult to balance security with CI/CD needs. This is where the principle of least privilege comes in. Team members gain access to secrets on a need-to-know basis. Note that this principle applies to everything from applications to connected systems and devices.

While most teams put this principle into practice, they leave the process as is. The lack of access audits, not the level of access, frustrates DevOps.

What do I do:

  • CISO should regularly engage DevOps teams when reviewing access to quickly mitigate issues. Including a security role within each delivery team will quickly mitigate access risks. The security team member will have insights into your risk-based access needs and can quickly approve or reject requests.
  • Creating an access management repository will also remove any confusion related to role based access. In addition, log time- and task-based access permissions to the repository. The result is that every DevOps team member will understand their access paths before projects begin. It allows them time to provide feedback and request one-time access to sensitive secrets.
  • Review the partitioning rules within your systems when assigning role-based access. Often times, these rules have to change depending on delivery schedules. Involving all stakeholders in these discussions is a good practice and prevents future frustration.

Implementing one-time passwords (OTPs) and other authentication factors is also a good idea when checking user access to secrets.

OSS Projects Review

Open source projects are essential to the growth of the industry but may pose security risks if access is poorly managed. Zan Markan, developer attorney at CI platform CircleCI, appropriately summarizes the problem.

“A company that started and owns a well-known open source software (OSS) project often continues to hire primary shareholders,” Markan writes. “They will likely be joined by other ordinary shareholders and supervisors who are not part of that company. And then there is everyone else—anyone who might occasionally contribute to a fix or a feature.”

As user access grows, security concerns grow exponentially. Enforcing strict user-based access is unrealistic and detrimental to the OSS project.

What do I do:

  • CISOs or other managers who focus on security should review whether sensitive secrets are passed during the creation of pull requests. Monitoring who can submit applications and the roles you are reviewing will ensure a good level of security.
  • Establishing machine identity is also critical, given the degree of need for non-human access pipelines. Authentication can be based on checking whether the attributes of a client runtime container match valid container properties. Once authenticated, it can take over role-based access, limiting access to secrets.
  • It is also a good policy to destroy containers and virtual machines (VMs) after they have been used.

Simplifying DevOps operations is a top priority

DevOps is critical to the success of every organization. Access and permission issues are common and can be easily avoided. Reviewing access and balancing delivery and operational needs is essential to maintaining a competitive advantage.

#solve #permission #issues #pipelines

Leave a Comment

Your email address will not be published.