86 What is the difference between Managed and Custom and Inline Policies in AWS IAM
HTML-код
- Опубликовано: 10 сен 2024
- 🎉AWS Certified Developer Associate Free Course:
tinyurl.com/dv...
🎉 Slides on the channel are available here in the link below:
ko-fi.com/pyth...
🎉 Pythoholic is Creating visual content for all tech and programming on RUclips!
You can support by buying a coffee ☕️ here -
ko-fi.com/pyth...
🍀 If you wish to support me please choose the links below:
INSTAMOJO: instamojo.com/...
PAYPAL: paypal.me/pythoholic
GADGETS I USE: www.amazon.in/shop/pythoholic
🎉AWS Solutions Architect Associate Certification 2021 Playlist:
tinyurl.com/y4...
Learn Once. Never Forget
🍀 RUclipsr @BePythoholic 🎲
🍀 ko-fi.com/pyth...
🍀 buymeacoffee.co...
🍀 Podcast (Blabber Cloud) : tinyurl.com/Pyt...
🎯 Click Below
🚨 RUclips -- tinyurl.com/PythoholicYT
Disclaimer: The content provided in the channel is not affiliated in any way to the organization. We provide information here on the channel based on the knowledge we have on the topic. We advise our viewers to please do their own research and read more about them from the source provided by the organization to get a better outlook on the topic that has been covered.
These videos are just to provide you a platform to learn, and there can be mistakes and we are always trying to improve based on your feedback. we recommend viewers have an open mind. Please support the channel to get more content like these in the future.
#AWS #Technology #Pythoholic
Can you show how to train AWS Sagemaker on your own custom container image instead of those provided by AWS?
One question, I think both - AWS managed, vs customer managed - are kinda interchangeable. I mean we can find an AWS managed policy for our own inline custom policy. Right?
AWS Managed Policies and Customer Managed Policies (or inline policies) in AWS IAM (Identity and Access Management) serve similar functions, but they have some distinct differences and are not always interchangeable depending on your specific use case. Here's a brief rundown of both:
1. **AWS Managed Policies**: These are policies created and managed by AWS. They are designed to provide permissions for many common use cases, such as Read Only Access or Full Access to specific AWS services. When AWS introduces new actions for a service, AWS managed policies for that service are automatically updated, reducing the management overhead for you.
2. **Customer Managed Policies**: These are policies that you create and manage in your AWS account. They offer more precise control over policies than AWS managed policies, and are useful when the AWS managed policies do not meet your specific needs. You're responsible for managing these policies, including updating them as new actions or resources become available.
So, while you can create a customer managed policy that has the same permissions as an AWS managed policy, the key difference is who is responsible for managing and updating that policy. If AWS introduces new features or services, AWS managed policies will be updated automatically, while you would need to manually update your customer managed policies.
In terms of inline policies, these are policies that you can create and manage and are embedded directly into a single entity (user, group, or role). They are not standalone policies, and as such, they cannot be shared. Inline policies are a way to ensure that the permissions in a policy are not inadvertently assigned to a different entity.
In summary, both AWS managed policies and customer managed policies have their roles in access management. If a pre-defined AWS managed policy fits your needs, it's often easier to use that. If you need more specific or fine-grained permissions, then a customer managed policy might be more appropriate. Inline policies can provide a high level of control, but they can also be more complex to manage, particularly in larger environments.
@@Pythoholic how so? To my understanding basically inline policy used to specify a number of actions or resources while in an aws managed one we do not have that luxury. We cannot change the access to resources or actions. If you are talking about this aspect of it I agree.
You're correct that inline policies provide more control over specifying permissions for individual IAM entities (users, groups, or roles), while AWS managed policies are predefined and cannot be modified.
To elaborate:
1. **Inline Policies**: As you mentioned, inline policies give you the flexibility to define custom permissions for specific IAM entities. You can write an inline policy to grant or deny access to specific resources or actions. This level of control allows you to tailor permissions according to the precise needs of each IAM entity.
2. **AWS Managed Policies**: AWS managed policies are predefined by AWS and cannot be modified. They are designed to cover common use cases and are generally broader in scope. While they provide a simplified way to assign permissions, they may not offer the fine-grained control that some use cases require.
In conclusion, inline policies provide more granular control over permissions, which is valuable in situations where AWS managed policies are too broad or don't cover specific needs. If you require a high level of customization for your IAM entity permissions, inline policies are the way to go. However, keep in mind that managing inline policies can be more complex, particularly in larger environments, compared to using AWS managed policies.
Thank you for the video. I have a question - how do you use AWS Managed Policy across accounts?
You create roles and assign managed polices the same way and just grant trust relationship for that account that u want to access
@@Pythoholic Thank you for the reply. But can't I do the same with customer managed policy? Isn't it the same process?
yes it is