Security

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
Using Quay.io to find vulnerabilities in your container images

Using Quay.io to find vulnerabilities in your container images

dtidwell
By Doug Tidwell

You’ve created a container image that has all the packages that you and your team need to do something useful, or maybe you’ve built a public image that anybody can use. But, what if that image contains packages with known security vulnerabilities? Regardless of the severity of those vulnerabilities, you’ll want to learn more and take steps to mitigate them as soon as possible.

Fortunately, your team uses Quay.io* as your registry. When you push an image to Quay.io, it automatically runs a security scan against that image.

Continue reading “Using Quay.io to find vulnerabilities in your container images”

Share
Go and FIPS 140-2 on Red Hat Enterprise Linux

Go and FIPS 140-2 on Red Hat Enterprise Linux

deparker
By Derek Parker

Red Hat provides the Go programming language to Red Hat Enterprise Linux customers via the go-toolset package. If this package is new to you, and you want to learn more, check out some of the previous articles that have been written for some background.

The go-toolset package is currently shipping Go version 1.11.x, with Red Hat planning to ship 1.12.x in Fall 2019. Currently, the go-toolset package only provides the Go toolchain (e.g., the compiler and associated tools like gofmt); however, we are looking into adding other tools to provide a more complete and full-featured Go development environment.

In this article, I will talk about some of the improvements, changes, and exciting new features for go-toolset that we have been working on. These changes bring many upstream improvements and CVE fixes, as well as new features that we have been developing internally alongside upstream.

Continue reading “Go and FIPS 140-2 on Red Hat Enterprise Linux”

Share