Security

Vault IDs in Red Hat Ansible and Red Hat Ansible Tower

Vault IDs in Red Hat Ansible and Red Hat Ansible Tower

sreejith
By Sreejith Anujan

This article demonstrates the use of multiple vault passwords through vault IDs. You will learn how to use vault IDs to encrypt a file and a string. Once they’re encrypted, the vault ID can be referenced inside a playbook and used within Red Hat Ansible and Red Hat Ansible Tower.

Starting with Ansible 2.4 and above, vault IDs are supported

Vault IDs help you encrypt different files with different passwords to be referenced inside a playbook. Before Ansible 2.4, only one vault password could be used in each Ansible playbook. In effect, every file needed to be encrypted using the same vault password.

To begin with, vault IDs need to be pre-created and referenced inside your ansible.cfg file. The following excerpt is from ansible-config list for the configuration DEFAULT_VAULT_IDENTITY_LIST:

Continue reading “Vault IDs in Red Hat Ansible and Red Hat Ansible Tower”

Share
API login and JWT token generation using Keycloak

API login and JWT token generation using Keycloak

emuhamma
By Muhammad Edwin

Red Hat single sign-on (SSO)—or its open source version, Keycloak—is one of the leading products for web SSO capabilities, and is based on popular standards such as Security Assertion Markup Language (SAML) 2.0, OpenID Connect, and OAuth 2.0. One of Red Hat SSO’s strongest features is that we can access Keycloak directly in many ways, whether through a simple HTML login form, or an API call. In the following scenario, we will generate a JWT token and then validate it. Everything will be done using API calls, so Keycloak’s UI is not exposed to the public directly.

Continue reading “API login and JWT token generation using Keycloak”

Share
Role-based access control behind a proxy in an OAuth access delegation

Role-based access control behind a proxy in an OAuth access delegation

sidde3
By Siddhartha De

In my previous article, I demonstrated the complete implementation for enabling OAuth-based authorization in NGINX with Keycloak, where NGINX acts as a relaying party for the authorization code grant. NGNIX can also act as a reverse proxy server for back-end applications (e.g., Tomcat, Open Liberty, WildFly, etc.), which can be hosted on an enterprise application server.

Continue reading “Role-based access control behind a proxy in an OAuth access delegation”

Share
Keycloak: Core concepts of open source identity and access management

Keycloak: Core concepts of open source identity and access management

akoserwa
By Abhishek Koserwal

Keycloak provides the flexibility to export and import configurations easily, using a single view to manage everything. Together, these technologies let you integrate front-end, mobile, and monolithic applications into a microservice architecture. In this article, we discuss the core concepts and features of Keycloak and its application integration mechanisms. You will find links to implementation details near the end.

Continue reading Keycloak: Core concepts of open source identity and access management

Share
How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale

How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale

rabreu
By raphael abreu

In this article, we’ll cover microservice security concepts by using protocols such as OpenID Connect with the support of Red Hat Single Sign-On and 3scale. Working with a microservice-based architecture, user identity, and access control in a distributed, in-depth form must be carefully designed. Here, the integration of these tools will be detailed, step-by-step, in a realistic view.

This article exemplifies the use of tools that can securely run your businesses, avoiding using homemade solutions, and protecting your services by using an API gateway, preventing your applications from being exposed to the public network. The use of an API gateway also provides additional access control, monetization, and analytics.

Continue reading “How to secure microservices with Red Hat Single Sign-On, Fuse, and 3scale”

Share
Verifying signatures of Red Hat container images

Verifying signatures of Red Hat container images

flozano
By Fernando Lozano

Security-conscious organizations are accustomed to using digital signatures to validate application content from the Internet. A common example is RPM package signing. Red Hat Enterprise Linux (RHEL) validates signatures of RPM packages by default.

In the container world, a similar paradigm should be adhered to. In fact, all container images from Red Hat have been digitally signed and have been for several years. Many users are not aware of this because early container tooling was not designed to support digital signatures.

In this article, I’ll demonstrate how to configure a container engine to validate signatures of container images from the Red Hat registries for increased security of your containerized applications.

Continue reading “Verifying signatures of Red Hat container images”

Share
3 steps toward improving container security

3 steps toward improving container security

dstrom
By David Strom

As developers increasingly make use of containers, securing them becomes more and more important. Gartner has named container security one of its top 10 concerns for this year in this report, which isn’t surprising given their popularity in producing lightweight and reusable code and lowering app dev costs.

In this article, I’ll look at the three basic steps involved in container security: securing the build environment, securing the underlying container hosts, and securing the actual content that runs inside each container. To be successful at mastering container security means paying attention to all three of these elements.

Continue reading “3 steps toward improving container security”

Share
Using Keycloak instead of Picketlink for SAML-based authentication

Using Keycloak instead of Picketlink for SAML-based authentication

sidde3
By Siddhartha De

The Picketlink project is now a deprecated module in Red Hat JBoss Enterprise Application Platform (EAP), so there’s a chance that Picketlink will no longer ship with the next release of EAP/Wildfly and that there will not be any fixes in the near future for the picketlink module.

Picketlink, however, is now merged with Keycloak, an open source identity and access management solution developed by Red Hat’s JBoss Community. In this article, we’ll present an alternative solution to the picketlink module. Some organizations use picketlink as the service provider to enable SAML-based authentication with a third-party identity provider (i.e., Active Directory Federated Services (AD FS), OKTA, PingFederate, etc.). In this, article, we’ll see how the keycloak-saml adapter can be configured in the place of Picketlink to enable SAML-based authentication with a third-party identity provider.

Continue reading “Using Keycloak instead of Picketlink for SAML-based authentication”

Share
Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7

Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7

jorton42
By Joe Orton

Getting an SSL certificate for your web server has traditionally been a something of an effort.  You need to correctly generate a weird thing called a certificate signing request (CSR), submit it to the web page of your chosen Certificate Authority (CA), wait for them to sign and generate a certificate, work out where to put the certificate to configure it for your web server—making sure you also configure any required intermediate CA certificates—and then restart the web server.  If you got all that right, you then need to enter a calendar entry so you’ll remember to go through the process again in (say) a year’s time. Even some of the biggest names in IT can mess up this process.

With new CAs like Let’s Encrypt, along with some supporting software, the rigmarole around SSL certificates becomes a thing of the past.  The technology behind this revolution is Automatic Certificate Management Environment (ACME), a new IETF standard (RFC 8555) client/server protocol which allows TLS certificates to be automatically obtained, deployed, and renewed. In this protocol, an “agent” running on the server that needs an SSL certificate will talk to to the CA’s ACME server over HTTP.

A popular method for using ACME on your Red Hat Enterprise Linux 7 server is certbot. Certbot is a standalone ACME agent that is configured out-of-the-box to work with Let’s Encrypt and can work with Apache httpd, Nginx, and a wide variety of other web (and non-web!) servers.  The certbot authors have an excellent guide describing how to set up certbot with httpd on RHEL7.

In this tutorial, I’ll show an alternative method—the mod_md module—which is an ACME agent implemented as a module for Apache httpd, tightly integrated with mod_ssl, and is supported today in Red Hat Enterprise Linux 7.  The mod_md module was implemented by Stefan Eissing—a prolific developer who also added HTTP/2 support to httpd—and contributed to the Apache Software Foundation, becoming a standard part of any new installation since httpd version 2.4.30.

Continue reading “Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7”

Share
DevNation Live: Easily secure your cloud-native microservices with Keycloak

DevNation Live: Easily secure your cloud-native microservices with Keycloak

editorial-team
By Editorial Team

DevNation Live tech talks are hosted by the Red Hat technologists who create our products. These sessions include real solutions and code and sample projects to help you get started. In this talk, you’ll learn about Keycloak from Sébastien Blanc, Principal Software Engineer at Red Hat.

Continue reading “DevNation Live: Easily secure your cloud-native microservices with Keycloak”

Share