Wednesday, May 24, 2023

CyberArk Conjur 12.9 and podman - how fix the logs rotation in case of issues

CyberArk Conjur is released as an appliance and shipped as container images to have a fast setup without errors.

The supported container runtimes are the following:


  • docker 20.10 or later
  • mirantis container runtime 20.10
  • podman 3.x,4.x


Working on several Conjur environments inside our labs or customers we have noted that logs rotation (conjur, nginx, cluster, etc) wasn't performed on podman but that was working correctly on Docker.


After some investigation with the beloved CyberArk support team, we found the solution:

conjur container needs to be re-created adding the capabilities AUDIT_WRITE :


podman run \ ... --cap-add AUDIT_WRITE \ ... registry.tld/conjur-appliance:12.9.0


To avoid some noise inside the nginx logs it's also required to add the following permission inside every Conjur container:



chmod 701 /opt/cyberark/dap/log/nginx


The CyberArk support team was great as usual to assist us and to work together to find the solution.


These issues are now tracked on the CyberArk docs and should be addressed soon. 

In case you had the same issue I recommend to contact the CyberArk support to get confirmation if this solution could apply also to your environment.




Thursday, April 13, 2023

SIGHUP Secure Containers: how do you choose the oci base image for your workload?

I believe it's important to start with a premise:

in this article I'll spoke about a product/service built and offered by my actual employer, SIGHUP

Nobody from my company asked me to publish this blogpost here, this are my honest opinion about Secure Containers.




Secure Containers is a service with a fee,  built by SIGHUP that brought container base image secure, hardened and updated. 

Developer work with containers and images, compared to the past, offer several advantages like standardisation, automation, and a faster release time.

One of the underestimated aspects of working with containers, is that it's necessary to start from basic images that must be chosen with due caution in order not to run into one or more of the following issues:

  • bugs
  • CVEs
  • outdated images
  • malicious code

It is clear that having constantly updated base images, which contain the least number of CVEs possible, is important because any problems, once my software has been deployed, are replicated in the container which we then find running in production environments.

Keeping the base images updated and secure is therefore a non-negligible activity, which becomes a task that must be adequately followed by someone in the company, removing them from other tasks.

Here Secure Containers service can help with the following advantages:

  • Comprehensive Container catalog
  • Proactively patched against all known CVEs and vulnerabilities
  • prometheus friendly images
  • Notifications, support status and planned obsolescence
  • supports and clear SLAs

If you are interested in Secure Containers, please read the dedicated site to find more info and FAQ where you have also the possibility to enable a free trial of the service.

If you like to read more about the security of container base images, check this article where I'll explain this topic deeper.

Friday, January 13, 2023

How is possible to have devs and security officers happy at the same time? Try Snyk!

Being able to work safely in cybersecurity requires knowledge, attention to detail, and a good software portfolio to rely on.


One of the tools that I've learned and used during the last months is Snyk.





Call Snyk tools is not correct because it's a security platform with a series of tools that could operate on every code built:

During the last few years, the lines of code produced were growing exponentially. The availability of tons of open-source libraries and containers has boosted the speed of developers, but how can we be sure that all these resources are safe?

How developers could be responsible for the security of their code and of the work made by someone else? How security officers could handle this scenario without being a bottleneck to productivity?  

Snyk could help integrate his tools in IDE, git repository, or in pipelines CI/CD with fast analysis and suggesting the solution of the detected issue  

To provide some examples Snyk could be installed as VSCode plugin, or could be set to scan git repositories and in case of an issue could open automatically a pull request proposing a resolution.

Snyk is also fully integrable in the customer environment, both for access and security policies, to be full compliance with the customer needs. Customizable dashboards and reports are also available to make security officers able to understand fast the security situation of a project.

Another interesting fact is Snyk has builded also an open-source vulnerability database that catalogues the vulnerabilities and provides examples and tutorials for devs.

The great news is that make a test it's easy because a free (limited) plan is also available!

If you could be interested to have more info about Snyk, please read the blog article published by my colleague Luca Bandini about our experience with Snyk, used also to check the code of Fury the Kubernetes distribution developed by SIGHUP.



Monday, November 21, 2022

CyberArk Conjur follower, system error and reboot during configuration: how troubleshoot it and verify the Postgres communication in the right way

During this period working on a CyberArk Conjur environment, we experienced a strange behavior during Conjur follower setup. 

The setup on the follower was starting, the seed received, imported, and expanded but after some other steps the process was hanging and ending with a generic "System Error".

After the error message, the Conjur follower was restarted. 

We did some troubleshooting inside the Conjur Follower pod and we have verified that the Follower was able to connect to the Conjur API leader successfully but it wasn't able to connect to the Postgres database and finish the initial replication.

The correct way to verify the Postgres connectivity from the follower to the leader is the following command:


echo "" | openssl s_client -starttls postgres -connect <lb_DNS>:5432 -showcerts


if the server certificate will be returned, the Postgres connectivity will work as expected.

In our case, we were unable to get the certificate, so this points us to the network LB where a colleague fixed the issue.

Thanks to CyberArk support which provided us the openssl command, easy to be executed from the container or any server. 
We did the same verification in another way but the openssl s_client could be found easily on containers and servers.

To have more explanation about openssl s_client and see more options, check this nice blog post.

Saturday, October 1, 2022

CyberArk Vault Synchronizer - CASVM035E Vault name is missing , how fix it

As you know one of the piace of Cybeark Conjur architecture is Synchronizer which is needed to receive the secrets from the VAUL.

Last week, I took charge of an abandoned Synchronizer 11.7 that was not working for a while and needed also to upgrade to the newest 12.7.

After the upgrade (check this link for the steps ), the windows service was unable to start and the log contained the following error:

[5] [main] FATAL VaultConjurSynchronizer.Service.SynchronizerService - VCSS006F Failed to start CyberArk Vault-Conjur Synchronizer Service: CASVM035E Vault name is missing.


After a search on google, we were pointed to the CASOS log error for the VAULT where documentations suggest calling CyberArk support .


Luckily in the case of a  Synchronizer, we fixed it easily by editing the file

C:\Program Files\CyberArk\Synchronizer\VaultConjurSynchronizer.exe.config


where the value of the key  INTEGRATION_VAULT_NAME. was blank, after we have filled it with the vault name (present in vault.ini) the service was able to run again correctly and the secrets sync was made.

Wednesday, September 21, 2022

CyberArk Impact 2022 world tour ! I'll be there and you ?

As you probably know CyberArk has a big annual event named Impact, and this year was run in Boston.

Over the past weeks, CyberArk has announced a great initiative named CyberArk Impact world tour that will be hosted in several cities around the globe.


If you are interested, here on this page you could find all the details:

  • cities involved
  • agenda
  • registration form


Personally, I'll attend the one in Milan scheduled for the 11th of October 2022.

I'm excited to have this opportunity to follow some interesting sessions and meet interesting people in person, see you there!

Friday, August 5, 2022

CyberArk Conjur , authenticators and integrations

During the past few weeks, I have described what a secrets manager is and I have given an overview of the architecture and system requirements of CyberArk Conjur. 

A secrets manager can't do his job if he can't talk to those who need to ask him for secrets, and that's where Conjur's magic comes in!

The "authenticators" are responsible of the authentication process in Conjur and they are specialised to make it in the most secure way depending on the service. 

Here is the list of the authenticators currently supported :

authnDefines the Conjur default authenticator. Authentication for both users and hosts is based on an ID and API key. 
authn-oidcLeverages the identity layer provided by OIDC to allow applications to authenticate with Conjur and retrieve secrets needed for connecting to services such as a database.
authn-iamEnables an AWS resource to use its AWS IAM role to authenticate with Conjur.

authn-azure

Enables an Azure resource to authenticate with Conjur

authn-jwt

Enables an application to authenticate to Conjur using a JWT from a JWT Provider.

authn-gcp

Enables a Google Cloud Platform resource to authenticate with Conjur

authn-k8sAuthenticates hosts that are Kubernetes resources, such as a Kubernetes namespace, deployment, stateful set, and others. Authentication is certificate-based using a mutual TLS connection.
authn-ldapAuthenticates users based on an LDAP directory.


By default, after the initial setup, authn is the only authenticator enabled and it's responsible of the Conjur access with username or API key (randomly generated between 51 and 56 characters). 

When integrations are needed, for example with a Kubernetes cluster, you need to activate and configurate the authn-k8s authenticator
This authenticator can establish a secure mTLS connection compliant with Spiffie framework, as described in the following diagram (click here for more details): 


If  you need integrations with cloud identities supporting JWT authentications, like Google Apigee, you will enable the authn-jwt authenticator that will perform the integrations as below:




These were just two examples within the multiple possible secure integration allowed by the authenticators, the following is more complete list:
  • Kubernetes (locali o cloud) 
  • API gateway
  • Jenkins
  • Ansible
  • Puppet
  • Terraform
  • Cloud services
If the scenario described sound interesting for your needs, Conjur can definitely be the right choice, so contact your sales representative at CyberArk or your preferred CyberArk business partner..