Red Hat Advanced Cluster Security for Kubernetes Reviews

We have implemented the solution to address the recent security issue in the Openshift Kubernetes cluster.

Stability is the most valuable feature.

The solution lacks features when compared to some of the competitors such as Prisma Cloud by Palo Alto Networks and has room for improvement.

I have been using the solution for 15 years.

I give the stability a nine out of ten.

I give the scalability an eight out of ten.

The technical support is good.

Positive

I give the initial setup a seven out of ten. The deployment time depends on the customer's requirements. Financial institutions take some time. The installation takes a few hours but the configuration takes days to weeks.

The deployments require one engineer and one architect.

We implement the solution for our customers.

Red Hat offers two pricing options for their solution: a separate price, and a bundled price under the OpenShift Platform Plus. The bundle price includes five products and is more affordable. I give the price an eight out of ten. The licensing options are annual and 36-month terms.

I give the solution an eight out of ten.

One person is required for the maintenance.

We serve customers of small, medium, and enterprise sizes. The majority of our customer base comprises enterprises.

I would suggest using Red Hat Advanced Cluster Security for Kubernetes for organizations that utilize OpenShift since both solutions are supported by the same vendor.

We use the solution to move workloads from monolithic applications to containers.

The solution is easy to install, manage and use.

The solution's price could be lower.

We have been using the solution for almost one year.

It is a stable solution.

It is a scalable solution.

The solution's technical support is good.

The solution's initial setup process is easy. It takes ten minutes to complete and requires only one executive to deploy and maintain it.

We purchase a yearly basis license for the solution.

I recommend the solution to others and rate it an eight out of ten.

For use cases, the segmentation use case is the most requested by our customers. Also, monitoring the container's behavior is one of the aspects customers request when it comes to segmentation. The other use case would be monitoring and detecting any abnormal behavior.

Segmentation is the most powerful feature.

The testing process could be improved; it would be great.

I have been using this solution for two years. Usually, when we implement it, we count on the latest version because of the patching and updates.

I would rate stability a nine out of ten.

It is a scalable solution because my clients are mainly enterprise businesses. I would rate scalability a nine out of ten.

The customer support is good.

Positive

The initial setup is moderate. It's about a seven out of ten where one is difficult, and ten is easy. It's pretty straightforward.

The deployment process depends on the environment and the scope of the implementation itself. Sometimes it takes a few days, from a month to two weeks, and sometimes several months. It depends on the deployment, the use case, the requested use cases, and the nature of the environment itself.

Maybe three to five people are needed for the deployment. The maintenance team usually represents fifty percent of the implementation team. So, for instance, if we have six people for implementation, we would need three people for customer support.

The pricing model is moderate, meaning it is not very expensive. I would rate it a seven on a scale of one to ten, where one represents cheap and ten represents very expensive. Additionally, it operates on a subscription-based model.

I would highly recommend it to our customers. Red Hat OpenShift is one of the most promising platforms and has a lot of installed briefs. Considering the security controls and features of this solution, it is mandatory nowadays. It comes highly recommended and is supported by our technical solutions.

Overall, it is an eight out of ten because it covers all the security features, and is reliable and scalable. Also, it is cost-efficient. However, some features are still not ready yet. In this case, you need to add some complementary solutions to provide the full picture of the security controls. On a scale of one to ten, if ten security controls are required to be covered, then Red Hat can provide six or seven out of ten. The remaining three to four out of ten are out of scope or not covered yet by the platform itself. So, it's necessary to consider some security controls out of the box, such as vulnerability scanner, static code analysis, dynamic code analysis, etc., to ensure that this platform can provide security controls across these containers.

For the first step, you create the cluster the same way you specify the hardware underneath. On the cluster, you starting creating projects, which are like virtual spaces. There is a physical cluster where you install Kubernetes. You install it on the data center. Each team creates their own virtual space.

The most valuable feature is the ability to share resources.

They're trying to convert it to the platform as a source. They are moving in the direction of Cloud Foundry so it can be easier for a developer to deploy it.

They're trying to create it so that it's easier, like on Cloud Foundry. If you specify some service, you just go to the marketplace on Cloud Foundry and find something you want to create, like a database of a certain size and CPU, and it's automatically created for you. In your application, you just create a manifest file where you specify the name of this source. If you automatically bind the application to that source, that would be like a database. There is no need to manually produce a database.

By binding your application to the source, Cloud Foundry automatically creates a connection for you for your source code. So you basically don't use any ODBC or JDBC objects for your source code.

You have to create multiple customer resource files, where you specify the port. Red Hat goes on top of Kubernetes.

The first time you deploy the port, it means you are telling Kubernetes that you want to stream some virtual machine called a port. Then, you specify another consideration file where you describe what image you want to deploy on that port as a container.

There are many steps, and you can run multiple containers on this port.

You can create another port which works like a load balance set. You can scale your ports for multiple ports and get multiple instances of your application for the load balance.

I would rate this solution 9 out of 10.