Cloud Identity and Access Management: Secrets Management

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.

Secrets and Secrets Management

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.

Best Practices for Cloud Secrets Management

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:

• Discover, onboard, and secure new secrets as they are created.
• Log all accesses and changes to secrets.
• Create and enforce a comprehensive secrets management policy with strict rules around secret structure (length, complexity, reuse, etc.).
• Restrict the use of hardcoded, default or embedded secrets.
• Make sure secrets are easy to change without the need for manual effort and without causing application downtime.
• Encrypt all secrets at rest and in motion.
• Distribute secrets only after proper authentication and authorization.
• Implement limited secrets based on the principle of least privilege, e.g. secrets that allow read-only access to specific resources, rather than root access to all resources.

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.

4 Secure Approaches to Secrets Management 

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.

1- Use Existing Configuration Management Systems

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.

2- Use a Secrets Server

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.

3- Use a Secret Server Plus a Secure Introduction Method

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.

4- Leverage the Cloud Platform's Secrets Capabilities

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.

The Role of Centralized Authorization

Centralized authorization provides fine-grained access control over the resources your users can access. Its basic components are:

1- Policy Enforcement Point (PEP)

PEP is implemented in the application. The application controls access by asking the Policy Decision Point (PDP) for a decision.

2- Policy Decision Point

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.

3- Policy Administration Point (PAP)

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.

Why Roles and Revalidation are Vital for Secrets Management

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.

Conclusion

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.