Documente Academic
Documente Profesional
Documente Cultură
• Current problem
• Storing API credentials on each instance
• Credential rotation
• Audits at instance level are impossible since credentials are same across hosts
• How does Instance principals solve the problem?
• Instance Principals gives instances their own identity, instances become a new type of Principal (in
addition to OCI IAM users/groups)
• Dynamic groups allows policy to be defined on instances
• In the Audit, you will see the instance Id making the API call
• Services that support Instance Principals - Compute, Block Volume, Networking, Load
Balancing, Object Storage
+Config Errors-------+--------------------------------------------------------+
| Key | Error | Hint |
+----------+---------+--------------------------------------------------------+
| key_file | missing | the full path and filename of the private PEM key file |
+----------+---------+--------------------------------------------------------+
[opc@webserver1 .oci]$
Java and Python SDKs and Terraform also support Instance Principal authorization
• Credential Distribution: are credentials distributed to customer instances automatically by the service provider?
• Auto Rotation: are credentials automatically rotated by the service provider?
• Per Instance Creds: are credentials scoped to a single instance?
• Default Identity: does every instance receive credentials by default?
• Identity/Instance: how many identities can be provisioned by instance?
• Instance Groups: can identities be provisioned to entire sets of instances or must it be done instance-by-instance?
• Specify group id
• Allow group id ocid1.group.oc1.. to manage all-resources in compartment Project-A
* In general, this verb does not include the ability The IAM Service has no family resource-type, only individual ones; Audit and Load
to create or delete that type of resource Balancer have individual resources (load-balancer, audit-events)
Conditions:
Syntax for a single condition: variable =|!= value
• 2 variable types: request (relevant to the request itself), and target (relevant to the resource(s) being acted upon in
the request)
• E.g. variable request.operation represents the API operation being requested (e.g. ListUsers); target.group.name
represents the name of the group
• variable name is prefixed accordingly with either request or target followed by a period. Examples
request.operation The API operation name being requested
request.permission The underlying permission(s) requested
request.region The key of the region the request is made in
request.user.id OCID of the requesting user
request.groups.id The OCIDs of groups requesting user is in
target.compartment.id The OCID of the compartment
• Policy for GroupAdmins group to manage the membership of any group besides the Administrators
group:
• Allow group GroupAdmins to use users in tenancy where target.group.name != 'Administrators'
• Policy lets A-Admins create, update, or delete any groups whose names start with "A-", except for the A-
Admins group itself
• Allow group GroupAdmins to manage groups in tenancy where all {target.group.name=/A-
*/,target.group.name!='A-Admins'}
• Compartments are the most effective mechanism for grouping resources when different
permissions should be applied to them
• Keep the following in mind when you create a compartment and assign resources:
• Every resource should belong to a compartment but resources can be
connected/shared across compartments
• A resource can't be reassigned to a different compartment after creation
• A compartment can't be deleted after creation
• We recommend using a separate compartment for network resources of differing
security levels and for each team/project
• Compartment: NetworkInfra
• Critical network infrastructure that should be centrally
managed by network admins
• Resources: Security Lists, Internet Gateways, DRGs, the top-
level VCN(s), etc.
• Compartment: ProdNetwork
• Production environment that may or may not be centrally
managed but is typically under change management
• Modeled as a separate compartment to easily write policy
about who can use (i.e. attach resources to) the network
• Optionally Databases and Storage may be included here
depending on whether they are shared resources or not
• Resources: Subnets, (Databases), (File Storage)
• Compartment: TestNetwork
• Integration test environment that may or may not be centrally
managed and may or may not be under change management
• Modeled as a separate compartment to easily write policy
about who can use (i.e. attach resources to) the network
• Optionally Databases and Storage may be included here
depending on whether they are shared resources or not
• Resources: Subnets, (Databases), (File Storage)
• Compartment: DevNetwork
• Development environment that is typically managed in a
distributed fashion to allow for agile development &
deployment
• Modeled as a separate compartment to easily write policy
about who can use (i.e. attach resources to) the network
• Resources: Subnets
• Compartment: ProjectXYZ
• The resources used by a particular team or project; separated
for the purposes of distributed management
• Resources: Compute Instances, Databases, Object Storage
Buckets, Block Volumes, etc.
• There will be multiple of these, one per team that needs it's
own DevOps environment
ProjectA
• John creates a Network in NetworkInfra compartment • Tom launches instances in ProjectA using the VCN in
• John can't terminate, reboot or launch new instances NetworkInfra compartment
into ProjectA compartment • Tom cannot launch instance inside the NetworkInfra
compartment
The instances Tom launched reside in the VCN from a network topology standpoint but from an access standpoint,
they're in the ProjectA compartment, not the NetworkInfra compartment where the VCN is
• Federated Roles is a set of OCI IAM groups that reflect roles within the organization.
• Federated Roles should be mapped to federated groups in a customer's corporate
directory. Group names do not have to match between OCI IAM and the corporate directory
but it's easier if they do
• Group: GlobalAdmins
• Group: IAMAdmins
• Group: NetworkAdmins
• Group: StorageAdmins
• Group: DBAdmins
• Group: ComputeAdmins
• Group: ProjectXYZOperators
• Only for enterprises with a notion of root or global admins already, otherwise omit in favor of the more
specialized admin groups below
• Group: IAMAdmins
• Tenancy-level policy: Note that there is no "family" resource type for IAM, hence the very explicit policy
• Group: StorageAdmins
• Tenancy-level policy:
allow group StorageAdmins to manage object-family in tenancy
allow group StorageAdmins to manage volume-family in tenancy
allow group StorageAdmins to manage file-systems in tenancy
allow group StorageAdmins to manage mount-targets in tenancy
allow group StorageAdmins to manage export-sets in tenancy
• Group: DBAdmins
• Tenancy-level policy:
allow group DBAdmins to manage database-family in tenancy
• Group: ProjectXYZOperators
• Project-level policy:
allow group ProjectXYZOperators to manage instance-family in compartment ProjectXYZ
allow group ProjectXYZOperators to manage volume-family in compartment ProjectXYZ
allow group ProjectXYZOperators to manage database-family in compartment ProjectXYZ