How to prevent user using elastic profile which is not their own

[X-Cloud Lab]

Hello,

I'm using GoCD EKS v22.1.0. I'm using it to run IaC on AWS.

I create an EKS cluster and create each profile for each squad team.

I also using gocd-yaml-conflig plugin to write pipeline as codes from GitLab.

So, the developers can write their own pipelines and using the elastic agent based on their profile.

For example, app-a-build-agents profile is for app-a squad team.

My question is how to prevent other squad team to use app-a-build-agents profile.

The other squad can configure their pipeline to use app-a-build-agents profile to configure AWS resources on Squad A AWS account.

This could be mistake or intend to do that.

Does GoCD has a mechanism to prevent this behavior?

Regards,

Worapoj

[Chad Wilson]

I haven't thought this through in detail however it might be possible to use GoCD's 'environment' concept to achieve this if different teams have different config repositories they have permissions on.

You can restrict which environments a given config repository has permissions to link pipelines to in its permission configuration.

I think (but need to double check) that you can also change elastic agent profiles so the elastic agents only register for particular environments using environment variables for the container (rather than any/all/no environment by default). That'd require different elastic agent profiles for different teams (or environment groupings) which it sounds like you have already.

If this approach works, team A would have to link their jobs to an environment in their YAML config. They *could* refer to a team Bs profile in their job YAML, but when the instance starts up it wouldn't register for the correct environment their pipeline is assigned to and the job wouldn't get assigned.

So it wouldn't prevent 'wasted elastic agent starts' due to misconfig but should prevent agent B from running team A's pipelines.

Can you perhaps experiment with environments and the agent auto-registration environment vars and see if that approach works for you?

-Chad

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/d6995a9a-da40-47cd-8306-a6af1e433bc9n%40googlegroups.com.

[X-Cloud Lab]

Thanks @Chad. I also tried this to create an agent profile with token i.e. app-a-build-agent-x9ym36re and store the agent profile name in GoCD's environment.

Then, I can config the environment permission for each config repo. However, elastic_profile_id in YAML file cannot refer to environment variable.

elastic_profile_id: "${env:AGENT_NAME}" or elastic_profile_id: "$AGENT_NAME" or elastic_profile_id: "${AGENT_NAME}".

Those always show an error in Config Repository page. By the way, it stills can echo to get the agent name.

[Chad Wilson]

Perhaps my suggestion wasn't so clear? I wasn't referring to use of environment variables - I was referring to assigning pipelines to GoCD logical environments (which can contain env vars for use during tasks) since a config repo can restrict which logical environments it refers to. https://docs.gocd.org/current/introduction/concepts_in_go.html#environment and https://github.com/tomzo/gocd-yaml-config-plugin#environment

As Aravind mentioned at https://github.com/tomzo/gocd-yaml-config-plugin/issues/160 environment variables are a task runtime concept, not something at config time. Similar to what was discussed at https://github.com/gocd/gocd/issues/10843

However, after a little bit of digging, I think my original suggestion will not work, as after a bit of digging, I concluded that even if you restrict the "logical environments" that an elastic agent registers for (e.g by manually setting GO_EA_AUTO_REGISTER_ENVIRONMENT=app-a-build in the Elastic Profile) I think anything you set there will get overridden by GoCD when the elastic agent is started, and set to whatever environment the pipeline needs - which would defeat the control purpose you are trying to achieve here.

So to support this, we probably would need to implement https://github.com/gocd/gocd/issues/10864 as raised by you already.

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/9722081b-e9a4-4a6f-998a-fca2742e3e12n%40googlegroups.com.

[X-Cloud Lab]

Thank you Chad for this explanation. I see you already mentioned the related issue.