Define Elastic Agent Extension v5

[GaneshSPatil]

Issue Type

• Feature proposal

Summary

Introduce elastic agent extension v5 to support cluster configuration related calls.

Introduce following new API calls related to cluster profile:

• Get Cluster Configuration Metadata
• Get Cluster Configuration View
• Validate Cluster Configuration
• Get Cluster Status Report
• Cluster Profile Changed

Introduce following new API calls related GoCD config migration:

• migrate-config

Modify following API calls to send along associated cluster configuration:

• Create Agent
• Job Completion
• Agent Status Report
• Should Assign Work

Modify following API calls to send along all cluster configurations:

• Server Ping
• Plugin status report page

Following API calls remain unchanged:

• Validate Profile
• Get Profile View
• Get Profile Metadata
• Get Plugin Icon

Capabilities API call changes have following capabilities:

• supports_plugin_status_report
  Indicates supports getting a status report at the plugin level. (An aggregated view of all the clusters)
• supports_cluster_status_report
  Indicates supports getting status report for a cluster.
• supports_agent_status_report
  Indicates supports getting a status report for a single Elastic agent.

Following messages will not be sent to the plugins implementing v5 extension:

• Get Settings View
• Get Plugin Settings Configuration
• Validate Plugin Settings Configuration

[kritika-singh3]

For adding support for cluster-status-report, we are thinking of the following URLs for all status reports:

1. Plugin status report:
   status_reports/:plugin_id
2. Cluster status report:
   status_reports/:plugin_id/cluster/:cluster_profile_id
3. Agent status report:
   old: status_reports/:plugin_id/:elastic_agent_id
   new: status_reports/:plugin_id/agent/:elastic_agent_id

Is it fine or someone has any other suggestion?

[zerolaser]

@GaneshSPatil @ketan Not sure if this is the right place to discuss about elastic agents or not.
With GoCD Elastic Agent Plugin for Amazon ECS

1. It asks for IAM users, can you convert it to IAM roles? Since anyway you're launching an EC2 instance with instance iam role, send those credentials to the docker instance. The issue with IAM user is it needs to be rotated with roles you don't need that.

2. We connect our GOCD to multiple AWS Accounts, the documentation doesn't say anything about connecting multiple aws account and launching docker agents based on the pipelines requirement.

3. It would be nice if agents are not owned by System administrator, just like template admin role, there should be an agent admin role. it should be configured in such a way that any pipelines having that role can pick up that agent. Teams can go at their pace. it's not the burden of the system administrator to launch new elastic go-agents based out of teams software requirements, his job is to configure elastic go-agents that's it. you might also need to consider about teams need update the go-agent version if go-server is upgraded, may be make older version stop connecting to it or throw error messages to handle that. Here at our workplace sometimes are using Nodejs version 10 while other teams are still using nodejs version 8.

4. May be don't add the AWS permissions at the plugin level, add it at the elastic agent level so the teams can add their own aws credentials here.

let me your thoughts on this ?

[bdpiprava]

@zerolaser -

1. It asks for IAM users, can you convert it to IAM roles? Since anyway you're launching an EC2 instance with instance IAM role, send those credentials to the docker instance. The issue with IAM user is it needs to be rotated with roles you don't need that.

It is not possible to replace the IAM user with a role as credentials are used by ECS plugin to communicate with the AWS API. We are considering following approaches of passing Profile/Role to the agent:

1. Passing the IAM Instance Profile/Role (provided in plugin settings) to the agent in question.
2. We can add another field in elastic profile settings for providing IAM Instance Profile/Role that will be passed on to the respective agent.

Second is a preferred approach. We may take that up in a future release.

2. We connect our GOCD to multiple AWS Accounts, the documentation doesn't say anything about connecting multiple AWS accounts and launching docker agents based on the pipelines requirement.

We are working on introducing multi-cluster support in upcoming GoCD 19.3.0 release. The plugin settings will be ported to cluster profile. So, you can have different clusters which support multiple AWS Accounts.

3. It would be nice if agents are not owned by the System administrator, just like template admin role, there should be an agent admin role. it should be configured in such a way that any pipelines having that role can pick up that agent. Teams can go at their pace. it's not the burden of the system administrator to launch new elastic go-agents based out of teams software requirements, his job is to configure elastic go-agents that's it. you might also need to consider about teams need update the go-agent version if go-server is upgraded, may be make older version stop connecting to it or throw error messages to handle that. Here at our workplace sometimes are using Nodejs version 10 while other teams are still using nodejs version 8.

• Elastic Agents are not 'owned' by System Administrators. Whenever we bring up an elastic agent, a job id is associated with it. The agent will get assigned to that job only. On completion of the job, the agent will get terminated. There is no role in play during these transactions.

• Elastic Agents Profiles can be configured by a group admin. When a job with elastic-profile is triggered, a call is sent to the plugin asking it to bring the elastic-agent (as described in profile) up.

• Agents are automatically upgraded on a server upgrade. No manual intervention is needed.

• In case of additional tools required on the agent (e.g. NodeJS), you can take any of the following approaches:

  • Create a different GoCD agent docker image for the NodeJS 10 and 8.
  • In your job, make the first task to install required NodeJS version.

4. Maybe don't add the AWS permissions at the plugin level, add it at the elastic agent level so the teams can add their own AWS credentials here.

Same as described for point 1.

/cc @arvindsv @gocd/committers

[arvindsv]

It would be nice if agents are not owned by the System administrator, just like template admin role, there should be an agent admin role.

To add to what @bdpiparva mentioned, we're planning to introduce more granular authorization soon (something similar to this). This should happen over the next two or three releases, once we finish secrets management support. That might allow finer control over elastic agent profiles. But, as @bdpiparva mentioned, currently, pipeline group administrators can manage them.

[zerolaser]

It is not possible to replace the IAM user with a role as credentials are used by ECS plugin to communicate with the AWS API. We are considering following approaches of passing Profile/Role to the agent:

@bdpiparva May be I was not clear with step 1. But you pretty much mentioned the same. Since you're already launching Ec2 instance and spinning up docker go-agents inside it. The launched Ec2 instance should have an IAM instance profile and while go-server triggers to launch a new docker go-agent, generate iam credentials using sts from the Ec2 instance's IAM role and pass them to docker go-agent. I don't know how the docker go-agent will utilize the role and do aws api calls. correct me if i'm wrong.

We can add another field in elastic profile settings for providing IAM Instance Profile/Role that will be passed on to the respective agent.
is this going to be a part of your multi-cluster release in 19.3.0 ?

Agents are automatically upgraded on a server upgrade. No manual intervention is needed.

The docker go-agents have a pre-installed version on go-agent. will those agents be upgraded or we need to pull-in the latest docker images from docker hub ? I thought we need to update them.

@bdpiparva With AWS fargate (for launching instances-less containers )being more cheaper. Does your elastic agent have capacity to support it? if not can you please add it to your roadmap ?

@arvindsv when are you planning on to release the granular auth ?

[arvindsv]

when are you planning on to release the granular auth ?

@zerolaser As I mentioned, it should happen over the next two or three releases, once we finish secrets management support. No known date yet.

[rajiesh]

Verified on 19.3.0 (8959-259d1f79e361875995072e5c1fcc9cbda7ccc600)

[timothy-cloudopsguy]

@bdpiparva With AWS fargate (for launching instances-less containers )being more cheaper. Does your elastic agent have capacity to support it? if not can you please add it to your roadmap ?

gocd/gocd-ecs-elastic-agent#243