Decoupling Consul's Role-Based Access Control (RBAC) from the core system.

[payalsu]

Changes proposed in this PR

The goal of this requirement is to enhance the security architecture by decoupling Consul's Role-Based Access Control (RBAC) from the core system. This change is aimed at allowing Consul RBAC to be installed and configured as a prerequisite, ensuring that the permissions required to install the application and the cluster level RBAC can be managed independently. By implementing this solution, we will improve access management, reduce security risks, and streamline RBAC architecture.
Goals:

• Decoupling RBAC: Implement a mechanism that allows Consul RBAC to function independently of the Consul cluster, promoting a modular architecture.

• Minimizing Permissions: Ensure that users responsible for installing the RBAC and application operate with the least privilege principle, mitigating the risk posed by overly broad permissions.

• Improving Security Posture: Enhance the overall security of applications by limiting the attack surface exposed to potential threats.

Benefits:

• Enhanced Security: Reducing cluster-wide permissions decreases the risk of unauthorized access and potential vulnerabilities.

• Easier Compliance: By enabling granular access controls, organizations can more easily comply with security standards and regulations.

• Operational Efficiency: Streamlined RBAC permissions management leads to a more efficient development and deployment process, reducing friction between teams.

How I've tested this PR

• Built the chart and deployed and tested with our Organization's product.
• Deployed Consul-RBAC as a separate chart maintained by us
• Tested new RBAC components to validate individual functions and logic. This included consul chart deployment along with other applications and ensuring normal functioning without any unexpected behaviors.

How I expect reviewers to test this PR

• Deploy/Verify manifest of the consul chart with --set global.rbac.create=false value and ensure that this will not create any RBAC resources
• Deploy with --set global.rbac.create=true value and ensure successful consul deployment along with RBAC resource creation.

Checklist

• Tests added
• CHANGELOG entry added

[hashicorp-cla-app]

All committers have signed the CLA.

[boruszak]

This pull request appears to be targeted spam.

[payalsu]

Hi @boruszak
May I know the reason for considering this PR as SPAM and closing it ?

This is a valid requirement from our organization. I have added enough explanation about the requirement. Is need more information or details, will be happy to answer .
Can you please RE-OPEN the PR ?
Thanks !!

[blake]

@payalsu Can you provide a little more detail as to why your organization needs to manage the RBAC permissions separately from the Helm chart? How do you plan to keep your external RBAC definitions up-to-date with changes to the Helm chart that require changes to K8s RBAC configs?

[boruszak]

@payalsu I closed the PR for security reasons. 1) This PR makes what appear to be substantial changes to the software's security operations, but the GitHub account is a month old, 2) there are no other contributions or indications of organization affinity on the GitHub account, and 3) the review request was targeted at the documentation review alias, despite the fact that the changes are not documentation changes.

Please respond to the questions from @blake, who can evaluate the pull request and decide whether to reopen it.

[payalsu]

Hi @blake
Our company is deploying Consul as part of a solution that runs on our customers Kubernetes environment. The customer manages the setup of the Kubernetes environment, including the creation of sensitive resources, such as RBAC. Our company is responsible for installing the application in that environment, but we don't have permission to install the RBAC.

As a result, we want the ability to add a feature flag to disable the RBAC installation and manage that using a separate RBAC specific helm chart. We will maintain that chart as we upgrade Consul to newer versions. I believe this use case is valid and it enhances security by allowing cluster administrators with higher levels of permissions to manage the sensitive RBAC resources, while restricting other users with less permissions to install the application itself.

If you require further clarification on this use case, I would be happy to provide more information.

[payalsu]

Hi @blake @boruszak

If everything looks ok , can this PR be re-opened ?

Thanks !!

[payalsu]

Hi
Can this PR be reviewed by the team please ?

[payalsu]

Hi
Can this changes be reviewed?