Eylam Milner
Aug 23 · 5 min read
There are many aspects to securing a software supply chain, and these keep changing and growing as technology advances. One security practice that has stood the test of time is the principle of least privilege. It was used in software systems decades ago, and continues to stay relevant in a world where the cloud and containers have brought about immense change at every layer of the software stack.
The principle of least privilege in software development is when a user is allowed to view, access, or use only the resources that are absolutely necessary to perform a task at hand. It is a foundational concept for security of software systems and is relevant in CI/CD pipelines that are used to build and deliver software today.
The principle of least privilege is a security measure that prevents developers from inadvertently introducing code that could either have a negative impact or can be turned into a black box that exposes the internals of the system to the outside world.
One way to make sure that users access only the resources they need to perform their tasks is by using groups and roles. Individual users and teams can gain access to the resources they need in a safe way that is deemed appropriate by the Admin or Ops team. Another word for this is RBAC – Role-based Access Control.
RBAC assigns each user and role a set of permissions. RBAC allows you to define who can do what in a system so that a privileged user can’t take advantage of a bug or another user to access confidential information.
The level of privileges defined in a CI/CD pipeline enables users to access and change resources in the software system. The Admin gets visibility into the usage of these privileges in the form of logs. As users access and make changes to files and code, it is captured in logs that represent an audit trail. This, however, is reactive, after any changes are made, and while it is helpful, what’s even more important is having a proactive stance towards access controls in CI/CD pipelines.
For certain high priority assets like databases with user information, or a server running in production, access is restricted only to a very select few users who are privileged users. Even for these users, it is important to not give them anytime access, but only time-based access to just the resources they need for a specific task. This is the principle of least privilege in action in a CI/CD pipeline. Giving users unfettered privileged access because of their job title or job function is a recipe for disaster. Even if not immediate, they can become prime targets for attackers who are looking for a way to escalate privileges.
There are a couple of ways to assign privileges in a CI/CD pipeline. You can allow only certain activities to be performed by a user which they need for their task, and disallow all other activities. Another approach is to allow them access to a subset of the resources – just enough to allow them to perform their activities. In practice, both these approaches will be combined for a more mature implementation of RBAC.
With most modern cloud-native systems being powered by Kubernetes, it is imperative for organizations to grasp how this works. RBAC in Kubernetes is different and more complex than with traditional systems. Kubernetes allows you to assign permissions to users or identities (who), to access resources in a single namespace or an entire cluster (where), so they can perform specific actions (what), and these permissions can be assigned directly or indirectly (how). With this many combinations, it is easy to get overwhelmed with enforcing the principle of least privilege in Kubernetes.
There are two concepts to understand when it comes to RBAC in Kubernetes – Role Bindings, and ClusterRoleBindings. RoleBinding grants privileges or permissions for a user, group, or identity at the namespace level. ClusterRoleBindings are very similar, except that they assign roles to users at the entire Kubernetes cluster level. ClusterRoleBindings allow Admins to configure multiple individual pods as one namespace and enforce rules on all of them. While this makes operations easier, it should be done cautiously as the wider the permissions, the greater the attack surface.
Enforcing the principle of least privilege in development environments’ CI/CD pipelines, cloud platforms, or in a Kubernetes cluster is all about balancing operational ease with security. No doubt, security is the more important of the two. However, in the constant push for being more innovative and faster, organizations compromise on security for the sake of moving faster. They assign wider privileges to many users to simplify processes. While temporarily, this is easy, organizations pay a steep price when the system is inevitably under attack and resources are left open for attackers to view, access, change, and steal.
The best way to enforce the principle of least privilege is to use policies that can adapt to how users and workflows change. These policies should be defined in a modern security tool like Argon where they can be frequently updated, and automated. Further, the policies should be bolstered with automatic notifications and alerts whenever a user attempts to escalate their privilege, or performs an action that is not normal for their level of access.
In summary, each component of your software supply chain is composed of smaller parts that are connected to each other. This means any small problem in one part of your application may affect the entire chain. Enforcing the principle of least privilege means to ensure that each component is secured and that users or identities cannot access sensitive data of the application from any of the smaller parts. Security principles are just as relevant today as they were in the past. However, today’s principles are more complex than those of the past. Thankfully, there are capable solutions like Argon that protect your CI/CD pipelines by making it easy to implement least privilege access and keep track of any violations.
DevOps has evolved into a standard practice of software development. According to…
Logging in to websites to access your accounts isn’t as secure as…
Today’s businesses and enterprises are heavily dependent on software and applications for…
Cookie | Duration | Description |
---|---|---|
__hssrc | session | This cookie is set by Hubspot whenever it changes the session cookie. The __hssrc cookie set to 1 indicates that the user has restarted the browser, and if the cookie does not exist, it is assumed to be a new session. |
cookielawinfo-checkbox-advertisement | 1 year | Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category . |
cookielawinfo-checkbox-analytics | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics". |
cookielawinfo-checkbox-functional | 11 months | The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional". |
cookielawinfo-checkbox-necessary | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary". |
cookielawinfo-checkbox-others | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other. |
cookielawinfo-checkbox-performance | 11 months | This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance". |
elementor | never | This cookie is used by the website's WordPress theme. It allows the website owner to implement or change the website's content in real-time. |
JSESSIONID | session | Used by sites written in JSP. General purpose platform session cookies that are used to maintain users' state across page requests. |
viewed_cookie_policy | 11 months | The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data. |
Cookie | Duration | Description |
---|---|---|
__cf_bm | 30 minutes | This cookie, set by Cloudflare, is used to support Cloudflare Bot Management. |
__hssc | 30 minutes | HubSpot sets this cookie to keep track of sessions and to determine if HubSpot should increment the session number and timestamps in the __hstc cookie. |
bcookie | 2 years | LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID. |
lang | session | This cookie is used to store the language preferences of a user to serve up content in that stored language the next time user visit the website. |
lidc | 1 day | LinkedIn sets the lidc cookie to facilitate data center selection. |
messagesUtk | 1 year 24 days | This cookie is set by hubspot. This cookie is used to recognize the user who have chatted using the messages tool. This cookies is stored if the user leaves before they are added as a contact. If the returning user visits again with this cookie on the browser, the chat history with the user will be loaded. |
Cookie | Duration | Description |
---|---|---|
__hstc | 1 year 24 days | This is the main cookie set by Hubspot, for tracking visitors. It contains the domain, initial timestamp (first visit), last timestamp (last visit), current timestamp (this visit), and session number (increments for each subsequent session). |
_ga | 2 years | The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors. |
_ga_1HW5JYG3DC | 2 years | This cookie is installed by Google Analytics. |
_gat_UA-191589358-1 | 1 minute | A variation of the _gat cookie set by Google Analytics and Google Tag Manager to allow website owners to track visitor behaviour and measure site performance. The pattern element in the name contains the unique identity number of the account or website it relates to. |
_gcl_au | 3 months | Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services. |
_gid | 1 day | Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously. |
hubspotutk | 1 year 24 days | This cookie is used by HubSpot to keep track of the visitors to the website. This cookie is passed to Hubspot on form submission and used when deduplicating contacts. |
Cookie | Duration | Description |
---|---|---|
bscookie | 2 years | This cookie is a browser ID cookie set by Linked share Buttons and ad tags. |
test_cookie | 15 minutes | The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies. |
Cookie | Duration | Description |
---|---|---|
AnalyticsSyncHistory | 1 month | No description |
li_gc | 2 years | No description |
UserMatchHistory | 1 month | Linkedin - Used to track visitors on multiple websites, in order to present relevant advertisement based on the visitor's preferences. |