Container Security Best Practices

Container Security: Best Practices for Secrets Management in Containerized Environments

Published November 30th, 2020 by John Walsh

Container security becomes even more important as container adoption increases the attack surface for nefarious hackers seeking to exploit insecure organizations. Containers are more in some wats secure, since they it easy to update an application’s underlying OS and dependencies. Despite this, using containers introduces new security challenges. Security becomes not simply about protecting what’s within containers, but also safeguarding a container from the applications inside it, inter-container protection, protecting hosts from containers, and protecting containers from a malicious or semi-honest host. 

Secrets management is critical to container security. Understanding what authentication and authorization secrets you need to control and where they are needed in your container is crucial. Learning how they are configured, stored, and managed can simplify the overall process of secrets management. If configured well, secrets management makes your entire environment more secure. 

In this article, we’ll look at some background concepts and best practices for ensuring authentication and authorization secrets are used effectively and securely in containerized applications.

Proving Identity, Authentication, and Authorization 

Secrets are digital credentials providing identity authentication and authorizing access to privileged accounts, applications, and services. Examples include: 

  • User or auto-generated passwords
  • API, GitHub tokens, and other application keys/credentials
  • Hard-coded credentials in containerized applications 
  • SSH Keys
  • Private certificates for secure communication, transmitting and receiving data (TLS, SSL, and so on)
  • Private encryption keys for systems like PGP
  • System-to-system passwords
  • One-time passwords for devices

Typically, these are the authentication details proving a user or system identity. Authenticated identities can then access or use systems based on user or group privileges defined within systems. For example, a web app running in a Docker container might need API key access to communicate with an external API or a username and password to access a database.

What are the Unique Challenges for Secrets in Containerized Apps? 

Containers contain specific layers requiring security: 

  • Images
  • The containers that run those images
  • The hosts that run those containers

Each of these layers is constantly changing as containers are dynamic and ephemeral environments, and applications running in containers often need to access external resources such as APIs and databases at different times.

As containers scale, it is more challenging to restrict secret access to only the containers needing them. Secrets may also persist on containers no longer running. Additionally, organizations deploying containers may face security risks due to a lack of duty segregation between different application containers, as well as between the application secrets and the container platform admin.

There are many ways to run containerized apps. Popular options include Kubernetes (often hosted on a cloud provider), Amazon Elastic Container Service, and Azure Container Instances. Many container runtimes come with a secret management solution, for example, Kubernetes Secrets, AWS Secrets Manager, and Azure Key Vault. However, these secrets management solutions have a drawback: vendor lock-in.

A container orchestrator such as Kubernetes or Docker Swarm helps with security, but can also create the problem of secrets management duplication. This is where secrets outside container environments need to be duplicated in the orchestrator, increasing the security risk unless secrets infrastructure changes altogether. 

Further, as cloud deployment is often in a multi-cloud environment, proprietary cloud secrets managers, such as Kubernetes Secrets, are unhelpful.

Docker is a widely-used tool designed to make it easier to create, deploy, and run applications by using containers. Organizations often run Docker with Kubernetes and OpenShift container orchestrators, multiplying security challenges. 

With CyberArk Conjur integrations, enterprises can take advantage of these micro-services by building powerful, secure container environments, with secrets management spanning all containers.

Best Practices for Securing Secrets in Containers 

Fortunately, there are many strategies developers can use to ensure container secrets are secure. These include:

  • Do not build secrets into the container image. To access container secrets, it may seem logical to build the secret value into the code or the container image by defining it in the Docker file. However, this means anyone with access to the source code also has access to information in code repositories, logs, and elsewhere. It also means functions such as rotating secrets and changing passwords require code rebuild and redeployment.
  • Avoid using environment variables for your sensitive information. It could be as easy as running docker inspect or exec in your container for hackers to find your secret.
  • When using Docker Swarm, lock your swarm to protect its encryption key. Similarly, when using Kubernetes, set the experimental-encryption-provider-config flag on the API server.
  • Regardless of where you store secrets, carefully map out exactly which containers need access to each of your secrets. Don’t share secrets anywhere they aren’t absolutely needed.
  • Implement role-based access control (RBAC). Adhere to the principle of least privilege, where an application only has access to the secrets it needs — no more, no less.
  • Limit secret access to the processes running inside a given container. 
  • Ensure it is possible to delete secrets which are no longer needed and revoke access to the resources it provided. 
  • To limit unauthorized access and prove compliance, it is important to regularly audit critical systems access. Central audit trails provide visibility into critical security events.
  • Rotate and change secrets regularly.
  • Log usage, including when a secret is injected, rotated, or removed from a container.

Consider using a centralized secrets vault, like ​CyberArk Conjur.​ Conjur offers the best of both worlds: your secrets aren’t locked into Kubernetes or one of the large cloud providers, and Conjur seamlessly integrates with popular tools such as  Kubernetes Secrets, AWS IAM, and Azure. 

Conjur is specifically architected for containerized environments. The solution tightly and seamlessly integrates with popular container platforms, helping developers centralize and simplify the management of secrets for containers across public or private cloud environments. 

With Conjur, each container or Pod is assigned a unique set of role-based access privileges for fine-grained control. Applications and services running in containers are uniquely authenticated, ensuring secrets are shared securely and only with their intended recipients. Central audit trails provide visibility into critical security events. 

Using the Conjur IAM Authenticator

The Conjur IAM Authenticator enables an AWS resource to use its AWS IAM role to authenticate with Conjur.

When you start a Conjur, set the CONJUR_AUTHENTICATORS environment variable to the IAM authenticator, and pass an environment name to it. For example, for an environment called “staging”:

CONJUR_AUTHENTICATORS=authn-iam/staging

You can then define the policy for the authenticator, defining secrets your container needs access to, and allowing the application to authenticate using the authenticator. 

The Conjur Azure Authenticator is a secure method for authenticating Azure workloads to Conjur using their underlying Microsoft Azure attributes. 

To use Conjur to authenticate with Azure active directory (AD), you first need a token from Azure, and you can then send an authentication request to the Azure API. Find out more details including set up in the associated documentation. 

The OpenShift and Kubernetes integration enables applications running in Kubernetes to authenticate with Conjur using the Kubernetes Authenticator.

First enable the authn-k8 Conjur plugin that exposes additional endpoints to Conjur to communicate with Kubernetes, then use the Kubernetes Authenticator Client or the CyberArk Secrets Provider for Kubernetes to facilitates communication with the authn-k8s plugin. Find out more details by taking a look at the documentation.

Wrapping Up

This article explored the challenges of secrets management arising from increased container use. Managing and securing application secrets has grown in complexity due to increasing multi-cloud environments across vendors and use of dynamic, ephemeral environments, increasing the chance of security risks and vulnerabilities. We shared some of the best security practices to ensure your secrets are stored and shared securely and detailed the benefits Conjur provides for securing container environments.

Ready to increase your container security with Conjur? Get started today by setting up your Conjur OSS environment and retrieve a secret from Conjur to your application. 

You can check out the Conjur technical documentation and GitHub for more information on doing this. 

You can also request a personalized demo, and take a look at the Conjur tutorials and blog to learn more.