Enable Management of Multiple Kubernetes workloads with Centralized ECS Delegate
pending feedback
R
Rubber Scallop
To reduce load on developer teams, our product team would like to maintain Kubernetes workloads through our Centralized ECS Delegate.
Currently, users that deploy into EKS have to create and maintain their own EKS delegates. This has been a pain point for our users and adds complexity to onboarding as well as overhead on the development teams.
Log In
A
Abhishek Thamman
pending feedback
A
Abhishek Thamman
We discussed this internally, and this is the summarized ask: "Lock the secrets manager process to a delegate and then make that secret available to other delegates/processes that can connect to the EKS cluster"
Having this would mean that the secret value would be passed from Delegate 1 to Harness Backend to Delegate 2. This approach would be insecure as the secret would have to be passed to the backend. We don't pass/store decrypted secret value in harness, and it is only present with the particular delegate where it got decrypted.
R
Rubber Scallop
Abhishek Thamman is there a possible workaround?
A
Abhishek Thamman
Rubber Scallop: I am afraid there's no workaround, as implementing the above would be a big security concern.
Shylaja Sundararajan
under review
R
Rubber Scallop
To add more details on the issue:
Restrictions on Service Accounts: JPMC imposes restrictions on service accounts, making IRSA (IAM Roles for Service Accounts) not a viable solution.
Delegate Misconfiguration: When setting up the connector to run the SAML assertion and obtain the secret, it runs on the wrong delegate. The delegate defined in the connector overrides the one defined on the secret connector, and the other delegates lack the necessary permissions.