Balance innovation and agility with security and compliance
risks using a 3-step process across all cloud infrastructure.
Step up business agility without compromising
security or compliance
Everything you need to become a Kubernetes expert.
Always for free!
Everything you need to know about Magalix
culture and much more
In every organization, passwords and keys continue to play an important role in user authentication and access. To secure the organization and its sensitive assets from unauthorized users and bad actors, these “secrets” must be managed and protected. But as the enterprise IT system grows in size and complexity, secrets management can be a difficult task for network administrators and managers.
In this article, we share four secure approaches, as well as numerous best practices to simplify this task. With a robust secrets management framework, organizations can optimize access control, minimize the attack surface, and mitigate security risks.
In enterprises, a “secret” could be any digital authentication credential, e.g. a password, encryption key, API key, authorization token, etc., that enables a user (human or non-human) to access an application, system, privileged account or other cloud resource.
Since so many secrets are now used in many different contexts in the cloud, they increase the risk of privilege abuse, cyber attacks, and data breaches. This is why secrets management is vital. It involves managing the entire secrets lifecycle from creation/generation to rotation and revocation. It standardizes the use of secrets, and prevents secrets sprawl that could hinder your ability to manage, maintain and secure them.
Moreover, centralized secrets management provides visibility, monitoring and governance, and embeds robust security controls within your cloud environment.
One key best practice – an automated secrets management system – removes (or at least minimizes) human involvement in creating, managing, distributing and maintaining secrets. This reduces potential failure points, and protects access to your cloud resources.
Some more best practices for robust secrets management:
In addition, never put secrets directly into source code because they can be easily discovered by bad actors, especially if housed in cloud-based code repositories. In 2019, almost 50% of data breaches were traced to the misuse of credentials left inside code. So store secrets separately from the code and configuration on a dedicated secrets server, or in a safe place within your deployment tooling.
When it comes to secrets management, organizations have several options. Secrets must be handled carefully, and each of these approaches enable security teams to do just that.
However, although all four are reasonable approaches to secrets management, they differ by the security level they can provide. That’s why it’s important to review the pros and cons of each approach before choosing any one.
Security level: Minimal
With a configuration management system, you can maintain enterprise assets, ensure they perform as expected, and keep track of the current state of applications. Many systems can also hold secrets, and help you manage them.
Pros: If you can control access to the deployment system and encryption keys, this is a reasonable approach to secrets management.
Cons: If too many people can read the secrets, it automatically makes them insecure. Also, changing secrets may require system re-deployment, which may be occasionally difficult.
Security level: Medium
The deployment server or application can authenticate with the secrets server using a password to get the secret.
Pros: You only need a reference to the secret in the configuration data and a server/application that talks to the secrets server. All requests can be logged, so it’s easier to detect and prevent unauthorized users from accessing the secrets.
Cons: You must remember the secret to the secret server password.
Security level: Medium-High
The deployment tooling communicates with the secrets server to get a one-time-use secret, and sends it to the application. The application gets the real secret from the secrets server and holds it in memory. If the one-time-use secret has already been used, the application raises an alert.
Pros: Operations personnel and deployment tooling cannot view the secrets directly.
Cons: The deployment tooling still needs one set of static credentials to the secrets server.
Security level: High
Some cloud providers offer cryptographically-signed identity documents to cloud-provisioned systems. This allows the secrets server to know the identity of the server, and read server metadata. It uses this information to authenticate and authorize applications, and provide required secrets.
Pros: This method leverages the cloud provider as the root of trust.
Centralized authorization provides fine-grained access control over the resources your users can access. Its basic components are:
PEP is implemented in the application. The application controls access by asking the Policy Decision Point (PDP) for a decision.
PDP is implemented in the centralized authorization system. It takes information from the application, consults its policy and then shares its decision with the application.
PAP is also implemented in the centralized authorization system. It may be a web user interface and API that tells the system who can access which resource.
Role-based access follows the principle of least privilege, and requires users, groups, services or components (e.g. virtual machines) to explicitly take on a separate role for privileged operations. It thus provides additional security in the cloud. It also provides better visibility and an audit trail for stronger access control.
In cloud environments, it’s vital to periodically check each authorization, and verify its validity and need. Revalidation verifies that only the right people (still) have access to cloud resources.
Validation can be automated based on certain parameters, e.g. an employee leaving the organization. Make sure you maintain a list of entities whose access must be revoked, especially if the system provides cached credentials like access. Validation can also be based on human judgment following either a positive confirmation where access is lost unless explicitly stated otherwise, or a negative confirmation where access is retained unless explicitly stated otherwise.
Are you rotating your Kubernetes secrets?
Kubernetes’ built-in secrets mechanism provides only basic security capabilities. Achieve better security and usability for secrets with secrets management policies from Magalix that warn you if your secrets are not rotated recently. Tighten your secrets management workflow with Magalix.
Prevent Kubernetes NetworkPolicy misconfigurations by enforcing policy as code