This seems to be simple, but what I'm testing here is to delete the Default Agent Pool, and adding it back with the same permissions. For some reason, the newly created pool is not accessible for any user, unless I add it directly to the Agent Queue Users.
When you create a new server, the Default pool available is accessible by all users and any explicit permissions must be set.
Is there a way to make any other pool behave as the Default Agent Pool and be available for all users when they are creating a new build/deploy?
Is there a way to give access to a whole project, instead of doing that adding user by user?
This is a normal phenomenon. Since this a new agent pool are created by your account.
Note: By default in an on-premises server, the only member of the
account-level Agent Pool Administrators group is the Team Foundation
Administrators group.
You need to make sure you had register the agent in the right way. And make sure there had been Network Service Work Account under Agent pool service accounts.
Users in the Agent Pool Service Accounts group have permission to
listen to the message queue for the specific pool to receive work.
In most cases you should not have to manage members of this group, the
agent registration process will take care of it for you. For Team
Foundation Server the service account you specify for the agent
(commonly Network Service) is automatically added when you register
the agent.
More info about the agent pool, please refer the link from MSDN: Scale out and administer your build and deployment system
Related
After importing an existing user pool into a new amplify application, i no longer have the option to delegate api access using user pool groups from the CLI.
Building an application using React and amplify. Used command line to create cognito user pool auth and then created groups within this user pool. This allowed me to delegate api access based on the unique user groups. Whooopeee! Then... I started building a second application with the same user pool imported. Tried to follow the same process from the command line and restrict api access using user pool groups but it seems that aws CLI doesn't even register the user pool groups and only gives me the options to restrict by guest and authentication. Does anyone have a solution to this problem? Thank you.
So, we have a "Compute Engine default service account", and everything is clear with it:
it's a legacy account with excessive permission
it used to be limited by "scope" assigned to each GCE instance or instances group
it's recommended to delete this account and use custom service account for each service with the least privilege principle.
The second "default service account" mentioned in the docs is the "App Engine default service account". Presumably it's assigned to the App Engine instances and it's also a legacy thing that needs to be treated similarly to the Compute Engine default service account. Right?
And what about "Google APIs Service Agent"? It has the "Editor" role. As far as I understand, this account is used internally by GCP and is not accessed by any custom resources I create as a user. Does it mean that there is no reason to reduce its permissions for the sake of complying with the best security practices?
You don't have to delete your default service account however at some point it's best to create accounts that have minimum permissions required for the job and refine the permissions to suit your needs instead of using default ones.
You have full control over this account so you can change it's permissions at any moment or even delete it:
Google creates the Compute Engine default service account and adds it to your project automatically but you have full control over the account.
The Compute Engine default service account is created with the IAM basic Editor role, but you can modify your service account's roles to control the service account's access to Google APIs.
You can disable or delete this service account from your project, but doing so might cause any applications that depend on the service account's credentials to fail
If something stops working you can recover the account up to 90 days.
It's also advisable not to use service accounts during development at all since this may pose security risk in the future.
Google APIs Service Agent which
This service account is designed specifically to run internal Google processes on your behalf. The account is owned by Google and is not listed in the Service Accounts section of Cloud Console
Addtiionally:
Certain resources rely on this service account and the default editor permissions granted to the service account. For example, managed instance groups and autoscaling uses the credentials of this account to create, delete, and manage instances. If you revoke permissions to the service account, or modify the permissions in such a way that it does not grant permissions to create instances, this will cause managed instance groups and autoscaling to stop working.
For these reasons, you should not modify this service account's roles unless a role recommendation explicitly suggests that you modify them.
Having said that we can conclude that remooving either default service account or Google APIs Service Agent is risky and requires a lot of preparation (especially that latter one).
Have a look at the best practices documentation describing what's recommended and what not when managing service accounts.
Also you can have a look at securing them against any expoitation and changing the service account and access scope for an instances.
When you talk about security, you especially talk about risk. So, what are the risks with the default service account.
If you use them on GCE or Cloud Run (the Compute Engine default service account) you have over permissions. If your environment is secured, the risk is low (especially on Cloud Run). On GCE the risk is higher because you have to keep up to date the VM and to control the firewall rules to access to your VM.
Note: by default, Google Cloud create a VPC with firewall rules open to 0.0.0.0/0 on port 22, RDP and ICMP. It's also a security issue to fix by default.
The App Engine default service account is used by App Engine and Cloud Functions by default. Same as Cloud Run, the risk can be considered as low.
Another important aspect is the capacity to generate service account key files on those default services accounts. Service account key file are simple JSON file with a private key in it. This time the risk is very high because a few developers take REALLY care of the security of that file.
Note: In a previous company, the only security issues that we had came from those files, especially with service account with the editor role
Most of the time, the user doesn't need a service account key file to develop (I wrote a bunch of articles on that on Medium)
There is 2 ways to mitigate those risks.
Perform IaC (Infra as code, with product like teraform) to create and deploy your projects and to enforce all the best security practices that you have defined in your company (VPC without default firewall rules, no editor role on service accounts,...)
Use organisation policies, especially this one "Disable service account key creation" to prevent the service account key creation, and this one "Disable Automatic IAM Grants for Default Service Accounts" to prevent the editor role on the default service accounts.
The deletion isn't a solution, but a good knowledge of the risk, a good security culture in the team and some organisation policies are the key.
I have recently made a program that listens to a PUB/SUB topic that is connected to a Gmail account. I have it all working fine. When a push notification arrives it will do different tasks based on the message content.
The problem is that I use a Service Account to connect to all the API's on Google Cloud Platform that I need. The Service Account allows access to ALL of our Gmail accounts in our organization. I need to somehow limit the access to a specific Gmail account.
The closest I could find to this issue was this question Impersonating list of users with Google Service Account. However, the only solution presented there was to turn my project into a marketplace app which I do not want to do.
I have tried setting up an Organizational Unit and trying to limit the scope to that somehow, but there seems to be know way (that I can find) to do it. I did try speak with Google Cloud Platform help but they didn't know the answer as it didn't quite fall under their area of expertise and referred me on to another help group, but I'm not eligible for them because I don't pay for support.
Edit: It doesn't actually appear that what I want to do is possible. I'll be going back to an OAuth2 method of authentication.
Understanding service accounts explains the possibilities:
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Now try to fit that impracticable intent into there ...
If you need to limit the access of the service account to user-specific resources, this can only be done on the application level, not the system level - since a service account can impersonate just any user identity; eg. in order not to mess up the ownership, when uploading files on behalf of a user. If you want 1 user identity to access 1 user-specific resource, why even use a service account? And when using a service account, why not just impersonate as the correct identity? This could even be hard-coded, if it's only 1 user identity. But nevertheless, it can only be done on the application level - but cannot be configured for the service account itself.
I was working on a requirement wherein there is a need to know which user/machine has actually created the instances.
For example if a Compute Instance has been created by a Service account, how do we come to know which user had created. Basically, the intention is if we could capture the IP address/MAC address to check for any security flaw ?
Any hints are more than welcome !!!
Listing members that can access a service account
Select a project. Click the email address of the service account that you want to allow the member to impersonate. Click the Permissions tab. The Members with access to this service account section lists the members that can access the service account.
You can find the entire process of impersonating service accounts in [1]
[1]https://cloud.google.com/iam/docs/impersonating-service-accounts#:~:text=Listing%20members%20that%20can%20access%20a%20service%20account,-Use%20the%20Cloud&text=Select%20a%20project.,can%20access%20the%20service%20account.
When a user invokes gcloud with the --impersonate-service-account argument, a log message is generated in the project where the service account is defined:
resource.type="service_account" resource.labels.email_id="sa-name#projectid.iam.gserviceaccount.com"
protoPayload.methodName="GenerateAccessToken"
When a GCE instance is created, a log message that lists the principal and the impersonator is generated in the project where the vm was created.
resource.type="gce_instance"
resource.labels.zone="us-central1-a"
protoPayload.methodName="v1.compute.instances.insert"
protoPayload.authenticationInfo.principalEmail="sa-name#projectid.iam.gserviceaccount.com"
The value you're looking for is in protoPayload.serviceAccountDelegationInfo. The caller's IP is in protoPayload.requestMetadata.callerIp.
I've created a service account I intend to use in our development environment, and since its credentials are checked into source control, I want to lock down its access to the bare minimum.
When spinning up new hosts, our app creates a new PubSub subscription, listens on the newly created subscription, then deletes it when finished. We chose this model over having a number of preconfigured/hardcoded subscriptions because the number of hosts scales up and down with time, we don't want host-specific config (In the form of a host-subscription map) if possible, etc. We want to have this same behavior in our local development environments ideally for debugging.
I created a specific "development" topic and granted our development service account the Pub/Sub Admin role, allowing it to attach subscriptions to that topic. I also granted the service account the project-level permission that allows it to create subscriptions. The service account can successfully create a new subscription and attach it to the topic, but when it tries to read from the new subscription, I receive a permission denied error.
I'm guessing this is because, when checking the newly created subscription, I notice that the service account that created it is not granted any permissions of any kind to that subscription. I would've expected the account that created a subscription to at least have read rights to it.
Is there a way for a service account to create subscriptions, attach them to a topic, and then read from that subscription... while not giving the service account access to any other subscriptions or topics? I'm aware I could just give the service account a "higher level" role with access to read all subscriptions, but that defeats the purpose of having a development-only account.
After your service account creates the subscription, it can call setIamPolicy on the subscription to grant itself read access to it. This works because you gave your service account the pubsub admin role on the project, which includes the ability to call setIamPolicy on any subscription in the project.
https://cloud.google.com/pubsub/docs/reference/rest/v1/projects.subscriptions/setIamPolicy