Tag: Amazon

  • Overture Maps’ Challenge to Google ¦ Frontier Model Forum’s AI Safety Shtick

    Overture Maps’ Challenge to Google ¦ Frontier Model Forum’s AI Safety Shtick

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A big-tech consortium goes toe-to-toe with Google Maps, and a big-tech consortium tries to fool AI regulators. (more…)

  • AWS Identity and Access Management (IAM) Roles and How to use Them

    AWS Identity and Access Management (IAM) Roles and How to use Them

    Amazon Web Services relies on the AWS IAM service to govern who is authenticated and authorized to use AWS resources. It plays a hugely significant role in AWS security–and so do its various identities. Let’s look in more detail at IAM roles and how they work.

    What is the Purpose of IAM?

    When you create an AWS account, it has a single sign-on (SSO) identity called the AWS account root user, which has complete access to AWS services and resources. To avoid potentially disastrous issues arising from this kind of unfettered access, IAM allows shared access to the AWS account via identities.

    Based on the security-first model, AWS restricts all actions for all identities by default–apart from the root user. This restriction enables us to manage granular access for identities following the principle of least privilege, so permissions are granted only as required to execute daily tasks.

    What are IAM Roles?

    AWS users, federated identities and AWS roles are the three major categories of AWS Identities. IAM roles are conceptually similar to AWS users, but whereas a user is uniquely associated with a principal(users/apps/etc.), a role can be assumed by anyone who needs it.

    Rather than passwords or access keys, temporary security credentials are provided to whoever assumes the role. This eliminates the overhead of managing users and their long-lived credentials.

    Any of the following entities can assume a role to use its permissions:
    ● AWS user from the same account
    ● AWS user from a different account
    ● AWS service
    ● Federated identity

    Structure of an IAM Role

    The two essential aspects of an IAM role are the trust policy (who can assume the IAM role) and the permission policy (what the role permits the user to do).

    Trust policies use specified conditions to define and control which principals can assume the role. They prevent the misuse of IAM roles by unauthorized or unintended entities.

    Permission policies define what the principals assuming the role are allowed to do.

    Types of IAM Roles

    AWS IAM roles fall into one of the following major categories based on their trust policies:
    ● Service role
    ● Service-linked role
    ● Web Identity role
    ● SAML 2.0 federation role
    ● Custom IAM role

    Service Roles
    AWS services are the trusted entity type for these roles, which are created to allow AWS services to perform actions on the user’s behalf. They do this by inheriting the permissions assigned to the service role.

    You might wonder why AWS services need permission to access each other. It’s because, by default, even AWS services have no access to the resources in the AWS account. However, service roles allow AWS services to access resources based on their requirements.

    Most AWS services rely on service roles for optimal functioning. For example, they allow Cloudformation to create and delete resources on the user’s behalf based on a YAML or JSON file. The Amazon EC2 IAM role is a special type of service role. EC2 relies on an instance profile as a container for an IAM role, which is then assumed by the applications running within the EC2 instance to perform actions the role allows.

    Service-Linked Roles
    A service-linked role is a unique kind of IAM role linked to an AWS service. It simplifies the process of setting up a service by automatically adding all the required permissions for a service to perform actions on the user’s behalf. It is predefined by the service. Most service-linked roles do not permit changes to trust or permission policies.

    Web Identity Roles
    A user assumes a web identity role when they log in to AWS using an identity provider (IdP) such as Amazon and Facebook. Users do not have an identity within AWS itself; in exchange for an authentication token, they get temporary security credentials in AWS that map to an IAM role that is authorized to use the resources in the AWS account.

    SAML 2.0 Federation Roles
    These roles are assumed by users who are included in an external user directory, typically within organizations. This enables federated single sign-on (SSO), so that organizations can give users access to the AWS console and CLI without having to create a separate IAM user for each person. An organization that manages its employees in Microsoft Azure Active Directory could connect to AWS directly and give its users access to the AWS console and CLI based on the permissions provided to the SAML 2.0 federation role.

    Custom IAM role
    Custom IAM roles do not fit any of the other categories and support scenarios other than the ones listed above.

    What is the Time Limit for Assuming a Role?

    An entity can assume a role for as long as the IAM role’s session duration property dictates. For example, if the session duration for a role is set at 12 hours, the temporary credentials will expire 12 hours after they are issued.

    If you assume the role using the assume-role* command, you can specify a value for the session duration using the duration-seconds flag, ranging from 15 minutes to the maximum session duration permitted for the role. The default duration is one hour, but it can be extended to up to 12 hours. The session duration can be adjusted by editing the role.

    What About Role Chaining?

    One role can assume another role in a process known as role chaining. Role chaining cannot extend beyond an hour on the user session; it doesn’t follow the role’s maximum session duration field.

    And Cross-Account Access?

    IAM roles are often leveraged to enable cross-account access – the process of leveraging a principal in one account for access to resources in a different account. Organizations often maintain multiple AWS accounts to segregate environments such as development, staging, test, UAT, and production, and they grant identities from one account permission to access resources in another.

    This could be to process data in the production account and then anonymize and copy it to the UAT account, so that the frequency and attributes of data are the same. This keeps the UAT environment as close to the production environment as possible.

    How do IAM Roles Differ From Resource-Based Policies?

    Both identity-based policies and resource-based policies are permission policies, but identity-based policies are attached to identities such as users, roles, or groups, and resource-based policies are attached to resources such as S3, Amazon SQS queues, or VPC endpoints.

    Identity-based policies specify the actions the identity can take and on which resources, whereas resource-based policies determine who is allowed to access the resource to which they are linked and specify the actions they can perform. Resource-based policies must be inline and not managed. This list provides details of which resources support resource-based policies.

    Where both identity and resource-based policies are present, AWS evaluates them together. An action is permitted if it is allowed in either or both policies. If either policy contains an explicit DENY, it overrides the ALLOW.

    You can provide cross-account access using just the resources policy rather than using a role as a proxy. This is achieved by attaching a resource-based policy on the resource you want to share. This resource policy comprises all the principals allowed to access this resource, in contrast with an identity-based policy, which specifies the resources a principal has access to.

    Using a resource-based policy for cross-account access rather than roles has advantages.

    When a user assumes a role, they cede the permissions they have in the trusted account so that they can secure permissions in the trusting account (account with shared resources). With a resource-based policy, the user keeps their permissions in the trusted account, and they also secure access to the shared resources in the trusting account. The principal can access both accounts.

    AWS IAM Roles Anywhere

    AWS IAM Roles Anywhere is a kind of service role that permits on-prem machines or workloads external to AWS (such as servers, containers, and applications) to access resources on AWS by acquiring temporary security credentials. This completely eliminates the headache of managing long-term credentials.

    Workloads are required to have X.509 certificates issued by a certificate authority, which must be registered with IAM Roles Anywhere as a trust anchor. Though a relatively recent use case, it marks a move toward minimizing the usage of long-term credentials.

    Benefits of Using IAM Roles

    ● No management of long-term security credentials
    ● Support for Single Sign-on (SSO) using SAML 2.0
    ● Support for web identity federation, allowing users to log in via popular external identity providers (IdPs), such as Amazon, Facebook, and Google
    ● Enhanced security posture because you don’t have to rotate and replace short-term credentials (An expiry is already associated with them).
    ● Support for use cases such as cross-account access, Identity federation, AWS IAM Roles Anywhere

    Key Takeaways

    IAM roles are key pillars supporting, not just the IAM service, but the entire authentication and authorization flow. Their value extends beyond applications such as cross-account access, AWS IAM Roles Anywhere, and identity federation, being important for enhancing any organization’s security posture substantially. When used to their full potential, they can be extremely useful in IAM.

  • Open Source Communities Need More Than Funding From Big Tech

    Open Source Communities Need More Than Funding From Big Tech

    In recent years, major players like Microsoft, Amazon and Google have increased their involvement in open source projects, providing both financial and technical support. More consistent contributions from big tech—whether in the form of people or resources—is exactly what the open source community needs. However, underdeveloped collaboration guidelines can lead to friction between large corporations and open source developers, which ultimately harms both parties. Friction jeopardizes tech companies’ ability to rely on open source for operations while leaving the open source community without the support it needs. To make their relationship more sustainable, both parties need to cultivate a greater level of trust, develop clear guidelines for collaboration, and prioritize community.

    Big Tech Contributions: Moving From Cash to Collaboration

    For years, major tech companies have used open source solutions in their tech stacks. But many open source developers—who receive little to no money for their work—have voiced concerns about companies that take more from the open source community than they give.

    In many ways, big tech has answered the call. For example, Amazon recently passed IBM as the fifth-largest contributor to open source projects. Companies like IBM and Amazon have a vested interest in supporting these projects—if open source projects are understaffed and underfunded, the quality of the solutions suffers.

    But many tech companies are grappling with an unstable financial environment, which makes hefty donations more difficult to justify. As a result, support from big tech often involves donations of their developers’ time. However, this is also challenging as tech companies like Twitter and Google continue to lay off the developers who were keeping many open source projects afloat.

    Yet, even before recent layoffs, collaborations between big tech and open source teams were strained. There’s a natural power imbalance between a corporation like Amazon and the open source community, which includes members who contribute to these projects in their free time, sometimes for little or no pay. Big tech developers must juggle the interests of the open source team they’re collaborating with and their own employer—with little guidance on how to do so.

    A lack of transparency and communication from big tech also puts open source developers in a tricky situation. Many developers need financial and personnel support but may not want to relinquish control of their solutions to an outside corporation.

    To alleviate this tension, big tech needs to establish clear, mutually beneficial guidelines for open source collaboration that prioritizes sustainability.

    Reconciling the Fraught History Between Big Tech and Open Source

    Past tensions between big tech and the open source community can affect collaboration if left unaddressed. For example, Microsoft has become one of the biggest contributors to the Linux kernel, but many open source teams still remember former Microsoft CEO Steve Ballmer calling Linux a “cancer” in 2001.

    To overcome this tension, big tech companies need to clarify their intentions from the beginning of a project. They should disclose their reasons for selecting the project, the developers who will work on that project and how their contributions will look. Open source maintainers also have a role to play here. They must properly vet these companies and inquire about their prior open source experience and strategies before welcoming them into the fold.

    One way to reduce the risk of power imbalances or other tension is by collaborating through a project like the Linux kernel. Google, IBM and many other corporations contribute toward Linux kernel, and this distribution of contributors creates a much more balanced playing field. Rather than one company assuming operational control, multiple companies play a small part in keeping the Linux kernel up and running.

    The Benefits of an Open Source Program Office

    While these guardrails certainly help, big tech companies also need to formalize their open source contribution processes. At Aiven, we’ve done this through our open source program office (OSPO), which helps us manage our relationships with the open source communities we rely on. OSPOs ensure organizations remain compliant with open source licensing and provide a foundation to expand their involvement with the community over time.

    When developing an OSPO, tech companies should be intentional about how they measure success. The most obvious metrics relate to the work developers do—for example, the number of features delivered, the number of fixes and the number of projects they contributed to. But OSPOs should also measure how developers contribute to the community itself, not just the projects within it. For example, do developers review work from other developers in the community? Do they attend conferences, write blog posts and share knowledge with other developers?

    Big tech leaders must place as much emphasis on community-building as they do the number of contributions developers make. If they don’t evaluate developers based on their engagement with the community, the developer is less likely to focus their efforts there, injecting toxicity into the communities they’re trying to support.

    Open Source Thrives on Collaboration. Let’s Keep it That Way

    The challenge of reducing the stress and burnout of open source developers can’t be solved solely through financial means. No amount of money will reduce the amount of work it takes to maintain an open source project.

    To make collaborations between open source teams and big tech sustainable, both sides need to prioritize supporting the community above all else and develop guidelines that support this mission. More sustainable collaborations will ensure that the open source community gets the support it needs while big tech continues to reap the rewards of the community’s innovations.

  • Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)

  • Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

  • 8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: New ideas bring low-power ML inference, and more big-tech jobs are going. (more…)