May is Identity and Access month in the Red Hat’s monthly Security series! Beginning in March 2021, the Red Hat Security Ecosystem team has provided an introduction to a DevOps Security topic in a regular fashion to help you learn how Red Hat weaves together DevOps and security to help master the force called DevSecOps. We explain how to assemble Red Hat products and our security ecosystem partners to aid in your journey to deploying a comprehensive DevSecOps solution.

Identity and Access defined

Typically when identity and access is mentioned in a Kubernetes context, it’s IAM, or Identity and access management.  These security methods control access to on-premises and cloud assets, applications, and data based on user or application identity and administratively defined policies. They are found in every stage of the DevOps lifecycle and can help protect against unauthorized system access and lateral movement. Taking a look at the different methods in Identity and Access, the following become a distinct, but related list:

  • Authentication is verifying the identity of users, services and applications.

  • Authorization is granting the authenticated users to specific resources or functions. In Kubernetes context, this is commonly referred to as role-based access controls (RBACs), which grant collections of users access to resources or functions based on their job responsibilities, simplify administration and onboarding, and reduce privilege creep.

  • Secure identity storage, such as secrets vaults and hardware security modules (HSMs), which manage and safeguard security credentials, keys, certificates, and secrets while at rest and in transit. HSMs are typically a physical device which securely stores digital keys through encryption to protect sensitive data.  Secrets Vaults are typically a software solution that securely stores and manages any type of secret, like tokens, passwords, certificates, and encryption keys.

  • Provenance, which in the context of containers, is the ability to verify the identity or authenticity of code or an image typically through some type of digital signature or attestation record.

Identity and Access integrated in DevSecOps

As seen in the DevSecOps framework below, Identity and Access is represented in each integration point in the life cycle. This makes sense as identity needs to be managed properly in each step of the way in DevOps. 

2021-6-8-Devops identity and access framework The table details some, but not all, of the common items to consider for identity and access in a DevSecOps life cycle.

Integration Point



Centrally provide IDE access to developers and ensure they only have access to development projects they are authorized to work on.  Red Hat CodeReady Workspaces uses RH-SSO to create, import, manage, delete, and authenticate users. It can use third-party identity management systems, like a secrets vault, to create and authenticate users.

Source Code Management

You want to ensure the right people have access to the right source code repositories and only allow commit permissions to code contributors. In Red Hat OpenShift, Identity Providers like GitHub and GitLab can be configured to access the SCM. Secrets Vaults extend this capability by centrally managing SCM access tokens or secrets.

Build Automation 

Developers don’t need edit access to the build system as builds should run automatically on a scheduled basis or per commits. With OpenShift Pipelines being part of Red Hat OpenShift, the default RBAC capabilities can be leveraged to allow specific permissions to the pipeline projects.

Base images can be checked during the  builds to ensure they come from trusted repositories and their checksums match with the distributor.

Binary Repository

Authentication and Authorization is a key consideration for Binary Repositories ability to stage or cache 3rd party dependencies from external sources to prevent users from using untrusted code in their applications. 

Container Registry

Follow a zero trust methodology to harden your container registry access as it is a critical part of the DevSecOps development cycle. With Red Hat Quay, you can remove anonymous access, integrate with an Identity Provider, and create Robot Accounts which allow specific fine grained permissions to specific repositories.

Container Orchestration 

In addition to user authentication and authorization to deploy and test container images, pod permissions are an important consideration in this step, especially if pods need to reference images across projects, from secured or private registries.  Using image pull secrets with a centralized secrets vault is a best practice.


Red Hat OpenShift Container Platform provides foundational Identity & Access features by integrating with Identity Providers, multi-tenancy with Project namespaces, and RBAC turned on by default.

In addition to cluster user access, secrets vaults provide essential functions for running applications, such as on-demand access to passwords for application services like databases. 

An HSM can be used to protect and store cryptographic keys with industry standard, tamper-resistant hardware so that applications can access sensitive data without getting direct access to the encryption keys.

Enhance and Extend Identity and Access with Red Hat Partners

Combining Red Hat OpenShift Container Platform identity and access features with Red Hat’s certified Ecosystem Security Partners provides holistic enterprise-ready DevSecOps. If you are looking to enhance and extend Red Hat’s security capabilities in Identity & Access, take a look at the following Red Hat Partners:

For more information, visit "Modernize and secure applications with DevSecOps," or talk to us at Enhance container security and adopt DevSecOps.

About the author

Dave Meurer currently serves as a Principal Solution Architect on the Red Hat Global Partner Security ISV team, where he owns technical relationships and evangelism with security independent software vendor partners of Red Hat. Before joining Red Hat, he spent nine years in the Application Security industry with Synopsys and Black Duck, where he served in similar roles as the director of technical alliances and sales engineering.

Read full bio