You can discover and automate privilege management based on policies.
Discover and maintain inventory for VMs
For cloud infrastructure and cloud identity owners, this feature helps you discover and maintain the inventory for all VMs running on AWS cloud service providers.
In Privileged Access Service:
- You can see all the VMs running on various different Cloud Service Providers.
- The inventory is updated if a new VM is created or an existing VM is deleted from the cloud service provider.
Use single sign on for cloud VMs
IT admins or Cloud Ops engineers can use their enterprise identity (For example their AD user credentials) and their favorite native client application to log into to the VMs running on the cloud infrastructure without using a shared local account.
With Privileged Access Service you can define which users:
- Have remote access to specific VM machines
- Can run privilege commands on specific VM machines.
An auditor can also discover who has remote access to VM machines running on the cloud.
Users can login to their authorized VMs using their on-premise enterprise identity, on Windows or Mac with their favorite native SSH client application such as Putty, SecureCRT, RoyalTS, mRemoten, or RDP client application.
You have the following:
- EC2 instances deployed into AWS
- 4 accounts with multiple regions
- AWS accounts you do not manage
- One VPC per region per account, 200 systems total:
- Each of the 5 regions has 20 VPCs
- Each VPC has 10 instances (5 Windows, 5 Linux)
You can set up all your EC2 instances with cagent enrolled systems. This enables your admins to login using Use My Account, and enables you to remove Linux SSH key access.
Set up IAM accounts
Create an administrative IAM account
You need an IAM for each AWS account you plan on testing with. If you don't have one already, create an administrative IAM credential for your use, or ask someone to do this for you. We recommend your IAM name matches your company's e-mail address.
Note: The use of root credentials is highly discouraged.
See Adding IAM user accounts for more information.
Create a discovery IAM account
You can use your administrative IAM when doing discovery, but a better practice is to create a separate discovery IAM that has just enough privileges for discovery. You need to create a new IAM policy for discovery, and add a new discovery IAM with the policy attached.
To create a new IAM policy and attach it to a new discovery IAM:
- Go to the IAM console in AWS.
- Click the Create Policy button and select the JSON tab.
- Replace the policy text with the following:
- Click Review Policy .
- Name the policy CompanyDiscoveryPolicy.
- Click Create Policy.
- Create an IAM user with your user's company email address. For example, firstname.lastname@example.org.
Note: Ensure you allow API access and save the access key and secret to your desktop.
- On the Permissions tab for your IAM, click Add Permissions .
- Click Attach existing policies directly.
- Filter the policies by your company name and check CompanyDiscoveryPolicy.
- Click Review and Add Permissions.
Configure EC2 discovery
Import AWS key pairs
PAS needs the private key pairs for your instances for login. For each of your key-pairs, add them to Resources / SSH Keys.
Configure Hyper-scalable PAS roles
EC2 discovery profiles optionally reference a number of Hyper-scalable PAS roles.
Create the following roles:
|Centrify Agent Auth Users||
Users in this role are permitted to login to systems enrolled via Centrify Agent.
|Centrify Linux Agent Administrators||
Users in this role are granted full sudo permissions on systems enrolled via Centrify Agent.
Centrify Windows Agent Administrators
Users in this role are granted full Administrators access on systems enrolled via Centrify Agent.
EC2 discovery optionally enrolls the discovered EC2 instances. Additionally, it configures UMA for Linux instances and gives your Centrify Linux Agent Administrators roles full sudo permissions.
EC2 discovery can optionally add discovered systems and accounts to sets. For example, creating manual sets similar to the following:
- Discovered systems
- Discovered systems without credentials
- Discovered local accounts
Configure discovery profile for EC2 state monitoring
You may optionally configure your discovery profile to monitor EC2 state changes and automatically incrementally add or delete systems without having to wait for the next discovery "run".
To do this, you must first configure the following:
- SQS queue used to receive the stage change events
- CloudWatch rule to send state change events to the queue.
To configure an SQS queue:
- Go to the SQS AWS console.
- Click the Create Queue button.
- For Type of queue select standard.
- For Name, enter ec2_state_events or choose a custom name.
- Leave the remaining fields with the default settings.
- Once the queue is created, remember the queue URL which will look similar to https://sqs.us-west-1.amazonaws.com/215634055688/ec2-state-events. You will need this information for the CloudWatch rule.
To configure an Amazon Event Bridge Rule:
- Go to the Amazon Event Bridge Console.
- Create an Amazon Event Bridge rule called ec2-state-watcher
- Navigate to Events > Enter Rules
- Select the default Event bus and set the Name to ec2-state-watcher.
Note: You can leave the Description blank.
- Click Create Rule.
- In the Event Source section, click the Edit button to display the Event Pattern Preview page.
- Set the following information:
- Event pattern: enabled
- Pre-defined pattern by service: enabled
- Service Provider: AWS
- Service Name: EC2
- Event Type: EC2 instance state-change notification
- Specific states: running, terminated, stopped
- Any instance: enabled
- Insert the following text:
"EC2 Instance State-change Notification"
- Select Event bus and set AWS default event bus to enabled
- Select Targets and set:
- Target to SQS queue.
- Queue to the name of your SQS queue
- In the dropdown, select SQS queue.
- For the select queue dropdown, choose the SQS queue you created.
Auto-deploy from the AWS cloud provider using a connector
You have the option to deploy a connector manually, but it's much simpler and more efficient to use the wizard to deploy a connector.
To deploy a connector:
- In the Admin Portal, click Resources > Cloud Providers.
- Right-click on a cloud provider Name to open the dropdown and choose Deploy Connector.
- Select an IAM User and Region. This will display the VPCs in the selected region for the IAM user account.
- Select a VPC and specify an AMI ID.
- Select a Subnet.
- Optionally select an IAM Role for the instance. For example, you can choose a role that will enable the AWS system manager.
- Enter a custom Instance Name.
- Choose a Security Group or create your own security group.
- Choose a KeyPair which will be used to launch the instance.
- Click Deploy Connector.
Once the setup is complete, the system will reach out to AWS and create the instance.
Note: In AWS can will be able to see the pending status under Instances. It will take a few minutes to create, spin up, and deploy the instance. During this process, the system reaches out to AWS, downloads the installer, install the software and any required dependencies, reboots, etc.
As part of the connector registration, the registration is modified to indicate deployment into an AWS EC2 VPC. This information is returned back to PAS enabling it to configure necessary setup on the PAS side. The connector is then used to surface that VPC.
To see the connector mappings, navigate to Settings > Resources > System Connector Mappings.
In the table, you can see the connector(s) used for each VPC. If desired, you can modify the connectors used to reach the VPC.
Note: When aconnector is deployed to a VPC, this information is set it up automatically.
A connector can be added if it's on premises, but the VPC mapping will need to be applied manually.